Forest Pack Q&A

#61 No problems with terrain texture painting; now we can paint where the forest will go.

Commenting out the fog related code in forestrendermesh was bad for me: Tree foliage became a uniform gray color, bark textures flickered depending on distance, and terrain textures were washing out. I had better results with Karen's solution. Even though this results in full bright trees.

Any guidelines for creating trees to use with this? I've been going through the trees that came with Torque and I've noticed that not all trees retain collision. Some trees have upside down trunks and/or trunks that are turned 90 degrees leaving foliage hanging in midair. This seems to only be a problem with the forest code as they render fine using fxShapeReplicator.

#62 The forest pack does not support animation, so it's important that you make sure the shape displays correctly without any animation applied. Some of the Torque trees are very ancient and may not be fully compatible. I'd recommend making your own (it'll look better and run faster anyway). You'll want to have two meshes - one translucent for foliage and one opaque - and only use two materials - one translucent and one opaque - for maximum performance and efficiency. I have some trees I'll release with the next update that work pretty well.

#63 I have integrated the Forest Pack into TGE v1.4.3. I am having a problem with the Forest::buildConvex function. Left alone, I get a severe framerate drop over time. I have tracked it to the following code that creates a new convex object of type ForestConvex:

ForestConvex* cp = new ForestConvex;
			
            mConvexList->registerObject(cp);
            convex->addToWorkingList(cp);

            // Initialize ForestConvex data.
            cp->mObject    = this;
            cp->mForest    = this;
            cp->mData      = ptr->getData();
            cp->mShapeInstance  = ptr->getShapeInstance();
            cp->hullId     = i;
            cp->box        = ptr->getObjBox();
            cp->mObjScale  = ptr->getObjectScale();
            cp->calculateTransform(ptr->getTransform());

If I comment out the code above I do not get the framerate decay, but as expected I do not get collisions. The problems seems to be in the fact that we try to create a new convex object of type ForestConvexType, but the following code is never able to find the convex object that was added to the working list on the next go around.

for (CollisionWorkingList* itr = wl.wLink.mNext; itr != &wl; itr = itr->wLink.mNext) 
            {
               if (itr->mConvex->getType() == ForestConvexType &&
                  (static_cast<ForestConvex*>(itr->mConvex)->mItem == ptr &&
                  static_cast<ForestConvex*>(itr->mConvex)->hullId  == i))

As a result, the code is continuously "newing" a ForestCovex all the time - which causes the framerate decay.
Does anybody have any ideas?

#64 I found the fix to the above problem is to add:

cp->mItem	   = ptr;

around line 785 in forestCollision.cpp so that the code in that area that looks like:

// Create a new convex.
            ForestConvex* cp = new ForestConvex;
			
            mConvexList->registerObject(cp);
            convex->addToWorkingList(cp);

            // Initialize ForestConvex data.
            cp->mObject    = this;
            cp->mForest    = this;
            cp->mData      = ptr->getData();
            cp->mShapeInstance  = ptr->getShapeInstance();
            cp->hullId     = i;
            cp->mItem	   = ptr;
            cp->box        = ptr->getObjBox();
            cp->mObjScale  = ptr->getObjectScale();
            cp->calculateTransform(ptr->getTransform());

I look in the original forestCollision.cc download .zip file to see if I somehow deleted that line, but it doesn't look like I did.

#65 @Greg Kreafle
how obvious is the improvement? i did the same changes but no significant jump in performance. i'm using 1.5.2 though

#66 You can get a good idea of the qualitative improvement by adding a printf in the code that actually allocates a new convex, and seeing how much console spam you get. You should normally only see allocations when you start colliding (or get close to starting) with an object you haven't hit recently. If it's broken you'll see lots of allocations all the time.

#67 I was seeing lots of allocations ALL the time...There wasn't necessarily a speed up, just the absense of my framerate working itself towards zero over a period of about 2-3 minutes.

#68 Yeah - the fix looks good. Darn, that code worked perfectly the first time I ran it, and I never found any other bugs in it... guess there really is no such thing as perfect code. :P

I think probably towards the end of your time period 90% of time is being spent traversing the working lists for collision queries.

#69 Hey guys,

I think I have a fix for the dim/no lighting issue. Try this:

Line 930 of forestRender.cc, make it look like:

// render non-translucent forest items first...
   glMatrixMode(GL_MODELVIEW);
   glEnable(GL_BLEND);
   glEnable(GL_LIGHTING);

   installLights();
   setupTexturing();
   initMaterials();

Notice the reordering of some of the setup code there. On my box, this seems to resolve the problem, but I'd like to confirm.

#70 I did few tests with the update, the tree model i used is oak2.dts, the one come with TGE 1.5.2 demo.

test 1
1) with forestRender.cc:line930 changes,
2) without LightManager::sgSetupExposureRendering(),
3) without LightManager::sgResetExposureRendering(),
result: trunk and leaves (billboards) still show very dark color even in day scene

test 2
1) with forestRender.cc:line930 changes,
2) with LightManager::sgSetupExposureRendering(),
3) without LightManager::sgResetExposureRendering(),
result: trunk shown full lit color in day scene and night scene, but leaves (billboards) still show very dark color even in day scene

test 3
1) with forestRender.cc:line930 changes,
2) with LightManager::sgSetupExposureRendering(),
3) with LightManager::sgResetExposureRendering(),
result: trunk and leaves shown full lit color in day scene and night scene

#71 So the third test works properly?

#72 PS - thanks a ton for helping debug this. :) I've been pulling my hair out trying to figure out what permutation of GL state changes actually makes things work.

#73 Echoing some thanks, this code has a lot of learning potential for folks and it's just incredible to finally be able to do this type of forestry in TGE!

#74 @Ben
no, a good result should be bright color in day scene and dark color in night scene. i'm appreciate the effort you put into this useful resource and sharing it with us, this resource should merge into future TGE release

#75 Is there anyway to get the source file for the tree used (in OBJ please)? I need to see how it is set up, and how that last detail level is created....

#76 Ben's reordering @line930 of forestrender.cc does light the trees. However it results in them being fully lit regardless of mission lighting conditions. Some trees do have dark foliage while others do not. Has to do with the way individual trees are set up would be my guess. LightManager::sgResetExposureRendering(); resolves that issue but then again it results in full bright foliage day or night.

@Ben: just wanted to add my thanks for releasing this, it is an incredible resource.

...if only we could make the lighting play nice...

#77 Hey guys,

I updated the Forest Pack install page on TDN with an updated version of the source code. Changes:

- Fix for infinite convex hull bug.
- Use alpha map for tree placement (and assert if no trees could be loaded).
- Turned off fogging in generally unused cases
- Many fixes of state initialization to coerce lighting to work better.

Give it a try and let me know if it works any better for you. If nothing else now you can get correct tree placement and collision behavior without having to hand-apply patches. :)

#78 This is great. I now have green trees. :)
I found a problem with collisions with the trees tho. It seems collision is only detected at the avatar and trees center. :-D It's kind of funny running partially thru a tree. :D You have made a fantastic resource here.
Now to test on painted terrain.
Thanks again for all the work you've done on this.

Edit to add:
It even works perfectly with hand painted terrains. Fantastic. :-)

and no beta post would be complete without a picture.

#79 Awesome! Thanks for checking this, Mike! :)

Anyone else who can test the latest release would be very much appreciated. If it truly does work for people I'll do another .plan this weekend, and spend some time on the docs.

#80 Thanks so much, Ben. I'll definitely try to check this out when I get the chance, and post pics as well.