Nurbs surfaces problems

Hello there,
I’m having some odd issues with my nurbs models on a couple of specific machines and was wondering if anyone had seen anything like these problems before.
In both these cases the applet in question runs without any problems on a variety of different windows platforms.

I’m rendering a bath from a mesh that includes some large weighting (to do squared off corners), this causes distorted shadows and reflections when run on a g4 Powerbook.
It looks like the surface normals aren’t being calculated correctly, I’m using GL_AUTO_NORMAL to do this.
If I change all the weights to 1 on that model then it renders correctly and I’ve been able to render other surfaces fine with varying (but low) weights.

I’ve been trying to manually set the normal map as a work around and here I’m drawing a blank.
Can’t seem to turn up a decent tutorial on how to do this or even any example code - everyone just seems to use auto normals.
The code I have currently is:

gl.glEnable(GL.GL_MAP2_NORMAL);
glu.gluBeginSurface(nurbsRenderer);
glu.gluNurbsSurface(nurbsRenderer, 8, knots, 8, knots, 4 * 3, 3, normpoints, 4, 4, GL.GL_MAP2_NORMAL);
glu.gluNurbsSurface(nurbsRenderer, 8, knots, 8, knots, 4 * 3, 3, ctlpoints, 4, 4, GL.GL_MAP2_VERTEX_3);
glu.gluEndSurface(nurbsRenderer);

(note - this isn’t the bath in question, this surface comes from the redbook, I’m just trying to get the normal specification correct initially)

When I enable GL_MAP2_NORMAL then I end up with a surface which only seems to be lit by ambient and without it
it’s lit but the whole surface has a single normal direction ((0,0,1) by the looks of it). The line where I give it the normal map makes no difference in either case.
Is there anything glaringly obvious I’m missing or alternatively can anyone point me towards some code where this is being done correctly?

The other problem I’ve been having seems specific to the Radeon mobility HD 3200 so this is very much a shot in the dark. It’ll draw nurbs surfaces of all kinds with no problems - unless you call that surface from a display list. Then you get nothing.
Plenty of other objects draw fine from lists, in fact polygons within the same list as the surface draw fine.
It’s an odd one.

Cheers for any help.
Hecaton.

Hi

At first, please use JOGL 2.0 RC3 or the latest development build if it is not already the case as JOGL 1.1.1a is no more maintained.

Secondly, do you use the default Java implementation of the GLU or have you modified the flag allowing to use the native implementation?

Thirdly, as far as I know, the Java implementation of NURBS is not complete, there are some missing things (and it is the same for those who use the same Java implementation in their API).

At last, maybe the computation of the normals is buggy on G4 PowerBook. Yours has an ATI graphics chip, doesn’t it?

Edit. Maybe double post your question on JogAmp.org to get more answers.

Watcha

I’m using JOGL2.0 but not the RC3 version I don’t believe.
Will give that a try - soon as I work out which bits I need.
The jogl.jar I’m using specifically comes via http://download.java.net/media/jogl/builds/archive/jsr-231-1.x-webstart-current/jogl.jnlp, though I’m using locally hosted versions of all the files since java.net has been a bit flaky recently.

I’ve made no modifications to any flags so I’m using the default Java implementation of the GLU I guess.

The NURBS are definitely working fine for me in most cases, on windows machines at least. We’ve only got the one mac in the office for testing currently.
The only thing I’m having problems with on my development machine is manually creating the normals - likely this is just the method I’m using though.

The powerbook has a geforce fx go5200 card.
Yeah, I’d figured it might just be the card screwing up the normals - hence the attempts to manually set them.

Will give the jogamp forums a try too then.

Thanks for the advice,
Hecaton.

The URL you mentioned points to JOGL 1.1.1a which is no more maintained for several years. You should rather use the official builds from JogAmp.

Dur. Now you mention it it’s right there in the link isn’t it?
I really ought to pay more attention.

Will give jogamp a go later on today.

Thanks,
Hecaton

This link points to JOGL 1.1.1a and should NOT be used anymore:
http://download.java.net/media/jogl/builds/archive/jsr-231-1.x-webstart-current/jogl.jnlp

I used JOGL 1.1.1a for my game and some Oracle servers had been down for some days, now there are problems with the signature :frowning:

I got started with converting to RC3, looks like it’ll take a while though.
I’m doing a few things in ways that are outdated and a bunch of other projects have jumped in front too.
Will come back and report when I get something working.

Thanks for your advice,
Hecaton.

Don’t worry, nothing has disappeared. You have to find where some calls have been moved (GL, GL2, GL3, etc…).

Right - finally got back to this and finished the conversion.
Spot of wrestling with the jnlp and it’s running ok on windows again.
Good to be up to date, thanks for that.

Looks like the hd 3200 is simply a write off - exactly the same results as previous.
As mentioned the latest drivers just don’t seem to handle display list/nurb interaction properly.
I’ll give up on that one for now.

Got a different issue with our mac now and it’s presumably down to this machine’s setup.
When trying to open the applet it gives a bad version error.

(java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method))

The gears demo (http://jogamp.org/deployment/jogamp-current/jogl-demos/applet-gears-launcheronly.html) causes the same problem too.
I’ve dug around and discovered it’s probably connected with the version of jvm on the mac but after fully updating and tinkering with the java preferences I’m making no progress.

It’s on Leopard 10.5.8 and is running java plugin 1.5.0_30-b03-389-9M3425.
I also tried toggling it back to 1.4.2_22 but then java didn’t appear to be firing up at all.

I’m a mac rookie so it could well be something obvious I’ve missed.

Any thoughts?
Hecaton.

sounds like something on that applet may be compiled with a version of java newer that what your plugin is running. Are you sure your java plugin is actually running on java 1.5 (you can check from the java console output). I do remember there was an issue on OS X 10.5 where even if you selected Java 1.5 from the Java Control Panel the plugin was still running Java 1.4.

Yeah, definitely 1.5.
‘JRE version 1.5.0_30-b03-389-9M3425 Java HotSpot™ Client VM’ is specifically what the console says.

My first thought was to try removing and reinstalling java but apparently this is a huge undertaking with macs - essentially reinstalling the os.
I’ll save that for a last ditch attempt.

Hecaton.

Got a little more understanding now and it turns out our mac is less than ideal for testing.
It’s pretty old and it’s 32 bit intel chip means no java 6 and so no applet.
I assume that means the gears demo uses 1.6 too. Either way - no more testing on that machine.

I’ve managed to get in contact with someone with some java 6 capable macs though but despite ensuring java 6 is active and first on the java properties list we’re still having no joy running either applet (gears demo or my project).
Unfortunately they’re on the other side of the planet to me making detailed testing is a bit tricky so I wondered if anyone else has had any problems running the current gears demo on a java 6 capable mac?

Hecaton.