Scene Lighting Patch

#1 Note:
This patch doesn't make it possible to cast shadows from a terrain onto another terrain..
The original code didn't allow this, and i haven't changed that since i regard it a low priority.
I prefer to continue to seperate terrain/interior code from the rest of the engine.
(especially considering that i'd rather write new (updated) terrain code instead at some point)
But if someone else feels like fixing this... ;)

#2 I think i managed to patch all my files ok...

Though i seem to be having a problem with persistchunk.h :

const char *getClassName() const
   {
      AssertFatal(getClassRep() != NULL,
         "Cannot get tag from non-declared dynamic class");
      return getProxyRep()->getClassName();
   }

--> Compiling sceneGraph/sceneLighting.cc
In file included from sceneGraph/sceneLighting.cc:7:
sceneGraph/persistchunk.h: In member function `const char*
   PersistChunk::getClassName() const':
sceneGraph/persistchunk.h:69: error: `getClassRep' undeclared (first use this
   function)

getClassRep seems to be declared in a console class... hmm...


When i uncomment that, it seems to compile (after fixing the #include's that are case sensitive).
However my terrain is not shaded... so obviously i did something wrong somewhere :)

#3 Hmm.. that's odd..

I 'checked out' the latest version of head, used the patch on it
(it failed on the project file somehow)

i moved the interiorproxy.* files to the interior directory.
i moved the the terrainproxy.* files to the terrain directory.
i moved all the other cpp/h files to the scenegraph directory.

then i Added the files to the project file manually.
compiled the whole project, i had no errors..

ran torque, loaded a map, moved some things around, changed the terrain

relit everything, and it worked!

What version of the torque engine did you test it against?

#4 Sander,

I applied it to my version of torque which is near enough HEAD.
I did not modify the interior code as the patch suggested, since i have removed it from my version of torque.

Is there anywhere in the code i can take a closer look at in order to determine my problem?

Terrain lighting is actually called oddly.

And finally, if you didn't guess already, im compiling on linux.

Thanks for any help.

#5 Okie,

I tried applying the patch onto the latest HEAD.
Alas, i got the infamous error about the `getClassRep' function.
(Also, there are a few places where you have not taken into account case sensitivity, e.g including "scenegraph/foo.h" instead of "sceneGraph/foo.h", but not hard to fix)

I do not know what magical version of torque you use Sander, but i know for certain `getClassRep' is only in the ConsoleObject class, and is not floating about anywhere.

AssertFatal(getProxyRep() != NULL,
         "Cannot get tag from non-declared dynamic class");

Regardless, changing it to getProxyRep() seems to work a bit better :)

After that, compiled it... seems to work now :)

#6 There's no need for sarcasm.
Like i said, i tested it on the HEAD version and it worked fine for me.
Maybe it has to do with different compilers?
I'm using visual studio .net 7.1
That should explain the case sensitive directory thing..
(it's case insensitive under vs.net)
I'm just trying to figure out why it works on my system, but not on yours..

#7 any news on this resource?
it will be added on cvs?

#8 Sander,

My comment was only meant to be humorous. Sorry if i offended you in any way with it.

Andrea,

Quote:
tg: this code is being reviewed for inclusion into CVS after the holidays

So i would guess Tim will be looking into it anytime soon :)

#9 Still odd that you have the problem but i don't.
What platform/compiler are you developing on/with?

#10 Sander,

Here is the latest.
I seem to encounter the lighting problem as soon as i remove the interior code from torque (which would include the InteriorProxy).
My guess is that something is going wrong due to the fact that i removed InteriorProxy (What else could it be? I didn't edit the terrain code.)

Since i applied the lighting proxy patch before i removed the interior code, removing the interiors was a really simple task (except for a few other bits of torque that want them, though that code is not directly related to the scene lighting). Though i didn't quite *remove* them - I just replaced Interiorinstance with a totally new SceneObject, removing any specific Interior code (that i either haven't implemented yet, or i don't need).

I'm compiling on linux with gcc 3.x.

#11 I'd like to integrate this patch into cvs. Does anybody have any outstanding issues, besides those already posted?

#12 there's a way with this patch to cast shadows on static shapes? it'd be a good add :)

#13 is this in the head?

#14 Okie, update :)

I have tracked down my terrain lighting problem down to the actual terrain lighting functions (the lightmap is a blank 0.5/0.5/0.5). So, whilst the proxy is working, something isn't quite right with the lighting of the terrain.


Another update :
Tracked down my problem to the TerrainProxy::lightVector function. The piece of code :

col += ambient + lightColor * colorScale * lightScale[lsi];

Fails due to lightScale[lsi] always being 0.0...


Kevin,

I don't think so. Though i really would like it if it were.

#15 Yet another update....

There appears to be a problem with this code's terrain lighting when there are no other objects in the scene that provide ShadowVolume's (which is my case).

Lets take a look at TerrainProxy::Light :

// build interior shadow volume
   for(ObjectProxy ** itr = litObjects.begin(); itr != litObjects.end(); itr++)
   {
	if ((*itr) == this)
         continue;

      // casting shadow from (*itr) onto (this)
      //      shadows put into 'shadowvolume'
      //      clipPlanes are planes that limit the shadows being cast
      //         (to prevent unused shadows being added to the shadowvolume)

      (*itr)->addToVolume(clipPlanes, &shadowVolume, light); /* interior addToVolume */
   }

Now, my guess is that when you have NO interiors in your map (as is my case), nothing will be added to the shadowvolume.
Why is this important? well, lets take a look at the lighting code in TerrainProxy::lightVector :

ShadowVolumeBSP::SVPoly * poly = shadowVolume.createPoly();
poly->mWindingCount = 4;
poly->mWinding[0].set(wPos.x, wPos.y, height);
poly->mWinding[1].set(wPos.x + lexelDim, wPos.y, height + xh);
poly->mWinding[2].set(wPos.x + lexelDim, wPos.y + lexelDim, height + xh + yh);
poly->mWinding[3].set(wPos.x, wPos.y + lexelDim, height + yh);
poly->mPlane.set(poly->mWinding[0], poly->mWinding[1], poly->mWinding[2]);

F32 lexelSize = shadowVolume.getPolySurfaceArea(poly);
F32 intensity = shadowVolume.getClippedSurfaceArea(poly) / lexelSize;
lightScale[lsi] = mClampF(intensity, 0.f, 1.f);

the value, "intensity" results in being 0.0, since "shadowVolume.getClippedSurfaceArea(poly)" returns 0.
And why is this? Well, theres nothing in the ShadowVolume to clip against of course :)
And of course, values in the "lightScale" array are multiplied against to get the lightmap values. Multiplying any number with 0 will give you 0 as the answer. (see previous post for the code that does that)

Any chance you could take a look at this Sander? :)

#16 Was this added to CVS at all?

#17 This patch has not been checked into CVS.