Let there be Fog.

Hey, I believe I have successfully implemented LinearFog and ExponentialFog in Xith3D, I have tested them both using JOGL for rendering and I think the LWJGL one works too but I haven’t tested it yet.

Currently it seems impossible to have more than 1 Fog node in the scenegraph but I haven’t the foggiest idea why this is. (hehehehe) I’m not sure if this is due to JOGL not being able to render more than 1 instance of fog or simply because my JOGL code is just sucky. So at the moment if two Fog type nodes are added the last one to be added to the scenegraph will be the only one displayed. I don’t really think too many people would really need > 1 Fog node in the scenegraph anyway? But it’s a start.

PICTURES:
No Fog:
http://www.users.on.net/~jwinters/nofog.jpg

Linear Fog:
http://www.users.on.net/~jwinters/linearfog.jpg

Exponential Fog:
http://www.users.on.net/~jwinters/exponentialfog.jpg

This is the list of files I ended up adding/changing (2 new files FogShader.java and FogShaderPeer.java). Basically all I did was copy the code from how Light nodes are already rendered in the scenegraph and apply it to Fog nodes, so it should fit in fairly nicely.

CHANGES:
View.java (scenegraph package - added instanceof check for Fog nodes if “nn” node variable is a state modifier)
ViewState.java (render package - added variables to store/support new FogShader class)
ViewStack.java (render package - added variables to store/support new FogShader class)
Fog.java (scenegraph package - added stateModifier = true)
FogShader.java (render package - newly created class to store rendering/shading information about Fog nodes)
ShapeAtom.java (render package - changed so that FogShader object in ViewState object is added as a shader correctly along with the LightingShader object)

RenderPeerImpl.java (render.jogl package - changed so that FogShaderPeer is registered shader class for FogShader class)
FogShaderPeer.java (render.jogl package - newly created class to handle rendering of fog)

RenderPeerImpl.java (render.lwjgl package - changed so that FogShaderPeer is registered shader class for FogShader class)
FogShaderPeer.java (render.lwjgl package - newly created class to handle rendering of fog)

Can somebody please tell me how I submit the changes/updates that I have made to the Xith3D code?

Also what is the difference between GL_EXP and GL_EXP2 fog modes in JOGL? Currently set ExponentialFog to use GL_EXP mode instead of GL_EXP2 mode (and LinearFog is set to GL_LINEAR mode).

Thanks.

nice going :slight_smile:

The best thing you can do is submit a patch.

If you are on linux, there are some instructions here: http://www.cpqlinux.com/patch.html (make sure you pass the ‘-Naur’ arguments to diff).

In windows, cygwin would work, but may take some learning at first. Otherwise, I know there are several efforts to port *NIX software to windows nativly, e.g. http://unxutils.sourceforge.net/

If this is too much, just give us the changed files :slight_smile:

Regardless of which option you choose - head over to http://xith3d.dev.java.net/ and submit a new ENHANCEMENT issue. Once you have created the issue - you can attach files to it.

The patch files are good because we can see exactly what you have changed at a glance. Using IssueZilla is good as the Issue can be more closely tracked and monitored. You can of course just upload the files to your web site and tell us where they are :slight_smile:

Thanks for the contribution!

Will.

MrSquid,

I found your issue in IssueZilla, but seems there are no attachments there…

I just added you to list of project Beta Testers, so you can comment on your issues and (I hope) create attachments.

Yuri

Sorry yeah, having a bit of trouble with the whole making a patch file thing at the moment. :frowning:

Is it okay if I just zip the files that I have changed/added and add a note as to where the changes are? Sorry again, I’m new to the whole making patches thing.

I’m sure that’s fine. It only means we have to do a ‘diff’ ourselves if we want to see the changes :slight_smile:

The other reason they are important is when there is a great deal of activity on the files you are changing which means the version you altered could be out of date, but I don’t think that will be a problem here.

Will.

Would be also good (but not necessary) to know the CVS revisions of files you were modifying (will make much easier to do correct diff) [if you use WinCVS, you see them in file list].

Additionaly, this will be really great if you also provide a test case (similar to those found in com.xith3d.test package), so we can immediately test merged results.

Yuri

Added zip file containing the OLD files I edited and the NEW files that I ended up with. Included is also a collection of 10 .txt files that were the output from the cygwin “diff” command when comparing the old and new files so hopefully they should help a bit. The old files that I edited are from the
“Xith3D_2004-05-03_cvs.tar.gz” file as downloaded from
xith3d.org/downloads/build/2004-05-03_cvs/ directory.

I will work on doing up a simple test case for it now, and hopefully submit it shortly as an attachment onto Issue 78 thingy also.

Argh, just noticed I forgot to remove a line I was using to test the code from FogShader.java, please remove line 98 of FogShader.java when using it, the line looks like this:
System.out.println(“Added some fog! numFogs=” + numFogs + “;”);

[EDITED POST: Added 2 x .java test files for testing of ExponentialFog and LinearFog nodes to Issue 78. Place files in com.xith3d.test package to compile, use Up/Down arrow keys to move forwards/backwards to see the effects of the fog - ExponentialFog settings might need some tweaking too, anything > 0.1f for fog density seems to be REALLY thick fog.]

Ben,

Thank you for your submission, I have merged your changes with the current Xith3D CVS HEAD and committed them. The test cases are working great under JOGL.

It was useful having the diff’s you created, thanks. In the future always use “diff -u” which creates unified formatted diff’s (which are slightly more readable). It is also best if possible to make changes against the very latest Xith3D from CVS as the community builds can be out of date. There is a section in the Getting Started Guide on this topic if you are new to CVS.

Will.

Hi,

I also added launch files for new demos, as well as changed fog color in tests to 0.2, 0.2, 0.2, so now the objects that are far away “blend” with default background color.

We should check the way Java3D deals with multiple fogs and if possible merge their colors programmatically (low priority).

Yuri

Kewl, thanks, glad to have helped. :slight_smile:

Also what is the difference between GL_EXP and GL_EXP2 fog
modes in JOGL? Currently set ExponentialFog to use GL_EXP
mode instead of GL_EXP2 mode (and LinearFog is set to
GL_LINEAR mode).

there are two possible, exponential functions (along with the linear function) that can be used to blend the fog color with the incoming fragment’s color. GL_EXP defines the function as f = e ^ -(density * z) and GL_EXP2 as f = e ^ -(density * z) ^ 2. this is all from the “red book.”

Sean

We could add a new RenderOption so that the programmer can choose which one to use. What do you think?

Will.

I have added a new Render Option named GL_EXP2 which when set will cause the renderer to use GL_EXP2 instead of GL_EXP.

I added a test in the Xith3DExponentialTest demo - press ‘M’ (note you can also use the -DXITH3D_GL_EXP=true command line argument). There is a fairly large visual difference between the two.

I noticed in the code some more variables:


                    gl.glHint(GL.GL_FOG_HINT, GL.GL_NICEST);
                    gl.glFogf(GL.GL_FOG_START, 1.0f); //default 1.0f
                    gl.glFogf(GL.GL_FOG_END, 50.0f); //default 50.0f

Should the start and end points be specified in the fog constructor rather than hard coded? What other options do we have instead of GL_NICEST? Should they be changable though another RenderOption or don’t they matter?

Will.

Yeah I meant to mention something about that, it sort of seems like both Linear and Exponential fog allow for setting of front and back distances and density as well as that GL.GL_NICEST rendering hint.

I just left it with some default values for each to try and keep the LinearFog and ExponentialFog nodes similar to the Java3D ones, although I’m sure it would be possible to allow the setting of density + front/back distances in both ExponentialFog and LinearFog nodes with minimal effort. Personally I don’t really know enough about JOGL/OpenGL to know what all the rendering options for fog are though? :-/

Ok, I’ve looked up the Red Book.

the hint can be (page 242):

GL_NICEST which indicates the highest quality
GL_FASTEST which indicates the most efficient option should be taken, and
GL_DONT_CARE to indicate that you don’t care.

OpenGL implementations can ignore these values entirely.

Now it would be good to check with an expert to see if the popular OpenGL implementations do implement this, and if they do whether it make much difference which one you pick.

If we decide to implement this, creating a “RenderOption” is probably the best way to go.

density is only used in the GL_EXP and GL_EXP2 equations (see Sylvie’s post for the equation), start and end are only used in the GL_LINEAR equasion which is (end - z) / (end - start).

As the calls to gl.glFogf(GL.GL_FOG_START and gl.glFogf(GL.GL_FOG_END are unnecessary with ExponentialFog, and gl.glFogf(GL.GL_FOG_DENSITY with LinearFog I have removed them to avoid confusion.

I have also updated the LWJGL impl to reflect these changes.

Will.

Awesome, so fog should be pretty much finished off then?

once we can find someone who knows the answer to the “hint” question (i.e. does it make a difference on nVidia and ATI cards), yes.

I guess we should post the question in the JOGL forum or another dedicated OpenGL forum.

Will.

Well, by definition, hints are just that. You tell the implementation what you would prefer and it will do whatever it likes. Hints, in general, are pretty useful in the lighting model area for speed. If you tell GL to do it fast, it will normally cut corners if possible.

The approach we’ve taken in Aviatrix3D is to expose everything, regardless of whether it has an effect or not. Stuff like hints, you just never know from one version of a driver to the next whether they make any difference. And, since for Xith3D it’s only a single GL state call per frame (if that depending on your optimisations), it will have zero performance impact. In AV3D, where we have local fog capabilities (different objects can have different Fog nodes associated with them) it’s made very little difference to our performance at all. Visually, I can’t even remember what I saw when testing to make sure the hints were being passed through.