Forest Pack Q&A

#21 Karen, that code is in the engine to exec a script file that has the same name as the forest. It does insert an extra period, it didn't bother me so much as I exec'd the forest file myself. You can remove the period in the ".cs" portion of that line.

#22 Forest.cc
line 539 change

dSprintf(forestFile,sizeof(forestFile),"%s.%s", getName(), ".cs");

into

dSprintf(forestFile,sizeof(forestFile),"%s.%s", getName(), "[b]cs[/b]");

#23 Thanks for your help.

i did also explicitly exec forest.cs (ForestItemData and newForest::onAdd) in my project. i guess now the problem is lied on my second finding, why mTotalItems (forestCreation.cc line 194) always return 0

#24 Thanks Ben. That was enough to get me going. I put my forest.cs in my mod directory (starter.fps) and exec'd it in main.cs like this:

// Load up common script base
loadDir("common");

//-----------------------------------------------------------------------------
// Load up defaults console values.
   exec("./Forest.cs");
// Defaults console values
exec("./client/defaults.cs");
exec("./server/defaults.cs");

That got everything loading properly. The only problem I had then was there in nothing in the docs stating that the path to the trees must be absolute.

IE: starter.fps/data/shapes/trees/myCoolTree.dts as opposed to ~/data/shapes...etc...

I now have a forest. Thankyou for this pack. It's awesome. :)

#25 I guess i'd found the problem, the problem lied on my addForestEntry() the terrain texture i passed to this method wasn't the texture i used for my terrain. previously i thought TGEForest pastes the terrain txture to tree location, but TGEForest works the other way round, it is based on terrain texture to insert trees.

right now i'm facing another problem, the trees i got are all in black color, is this lighting issue or the texture problem?

#26 The tree models i used are oak1.dts, oak2.dts and shrub.dts, i got them from TGE demo, i able to see texture color by using showtoolpro, anyone has encountered similar problem?

#27 @Karen Ho -

Quote:
This is due to some Lighting Kit changes. The last update pass was on 1.5.0. If you look on Forest, there are installLights() and uninstallLights() methods. Those used to be on SceneObject and setup and tear down the GL lighting - but they got moved into sgSetupLights() and sgResetLights() on the LightManager class. So I stubbed them out and made them call the LightManager methods.

Ben said this toward the beginning of the post. It's not a texture issue so much as it is a lighting issue.

#28 A few comments from my test:
1) for some reason, the script is still said to be missing in the console.log, but parameters are handled as they should.

2) Until I uncheked single block only, my trees weren't visible, but the collision were performed.

3) the number of trees generated can grow up very very quickly; my test quickly ended up with more than 20,000 trees (6 different shapes).
As I understand it - I can be wrong, of course - the only way to decrease the number is to increase the radius per tree (spacing between shapes).
Wouldn't a solution calculating spacing, based on a maximum number of trees allowed, be simpler to handle on the human side? The spacing could be granted a bit of randomness to give it a more natural look.

#29 Thanks for releasing this pack Ben! Here are some issues/questions I have:

1) What is the best way to export a tree for this? I am a little confused about the billboarding. Are the billboards being generated automatically, or are they coming from the dts? If they do come from the dts, what is the point of adjusting the billboard distance?

2) The trees lose all their lighting when being viewed at certain angles. I suspect it has to do with the forest object being culled even though it is still rendering.

3) Are there speed advantages to this solution compared to a standard shape replicator? If so, what are they?

Thanks!

#30 @Karen Ho: As long as it gets the data, all is well. The exec is there as another way to get the config info, but if it fails it's not a problem - as long as the data is present!

Also - in my tests - the trees were full-bright, not black. This is, as Michael notes, due to some Lighting Kit changes that have not been reconciled completely.

@Stephan:

1) See Karen's reply - you can nuke the Forest::onAdd's exec if you're getting the data in another way.

2) Probably the forest was showing up on another repetition of the terrain block, where you weren't. The collision happening is a bug.

3) You're quite right. You have to be careful. There are several mechanisms to control tree density in addition to the radius - for instance, you can set the number of each tree allowed in each terrain grid square, which effectively gets you spacing-based-on-desired-count. The problem with a global solution (ie taking a total desired number and placing them evenly) is that it's hard to get an even distribution without it looking very regular and thus unnatural. The placement logic and rules are by far the most tweakable part of the pack, and if you're serious about using it you might want to consider adding your own placement rules. If you saved off the list of forest items + placement to a file, you could even make the forest entirely editable (but then client and server would have to keep that file in sync).

@Peter:

1) For best performance, try to use only two materials in each tree, a translucent one for the leaves and an opaque one for the trunk. The billboards are generated using an extension to the TSLastDetail functionality - so you need to specify a billboard detail level when exporting. See your exporter docs for how to do this.

2) Hmm - I'd suspect it's due to some oddity with the lighting kit. Can you tell if the lighting goes away when they switch to billboards, or if it's certain billboard views that are broken? Or is it the meshes? Is it related to if certain other objects in the scene are in view? The Forest object itself goes to some lengths to avoid ever being culled, but there could be other interactions happening here.

3) Yes, it's MUCH faster than a shape replicator. Try a few simple tests - for scenes with a thousand trees or so you should see something like a 10x speedup, maybe even more. A fully GPU-oriented solution is faster, but this system is approaching optimal performance on older fixed function hardware.

#31 TGEA version... :(

#32 @Ben - I have one quick question regarding view distance. Is there a script/engine variable for increasing the distance? I'm seeing billboards or no trees at all within 10 meters, which is a bit overkill. I'd like to start culling and billboarding a greater distance to maintain realism. I've read the previous posts and haven't quite pinpointed an answer. I'm used to the view distance variables for replicators and fog, so I might be looking in the wrong places. Any suggestions?

#33 @Michael: Hmm - that's a weird one. Are you using standard shapes? Have you done any other engine mods? Against 1.5.2 freshly downloaded from the website, it all worked just fine - in any case, it uses the normal visibility/LOD selection logic, so it should be using pixel size of the trees + fog settings to determine what's visible or not.

#34 @Chris: I replied in the .plan thread.

#35 @Ben - I'm using AFX 1.5.2 with a few mods added in:

• PhysX[li]BatchedDecalRendering[li]ClusteringFoliage[li]DynamicLightCoronas[li]extrudedPolyList Fix

I might try starting with a fresh download of AFX 1.5.2, add the Forest Pack, and start adding resources back in from there.

#36 @Ben: Gotcha. :)

#37 Is there anyway to get "groupnum" of the texture drawn by "terrain texture painter"? what i intended to do is to "spawn" trees on certain terrain texture drawn by terrain texture painter. right now TGEForest only get the baseMaterial type and ignore the "painted texture"

//forestCreation.cc line 146
groupNum = terrain->getBaseMaterial(x, y);

#38 So this cant be used with painted textures?

#39 From documentation:

Quote:addForestEntry takes four parameters. First, the name of the ForestItemData that describes the type of tree being added. Second, the terrain texture that this type of item should be placed on. Third, the probability of being found on that type of texture (0-100). Finally, the density, which corresponds to how many of those items will be found per terrain square (8m by 8m by default).

function newForest::onAdd(%this) 
{ 
   %this.addForestEntry("ChristmasTree", "starter.fps/data/terrains/grassland/grass", 15, 5);
   %this.addForestEntry("SeethroughTree", "starter.fps/data/terrains/grassland/grass", 15, 5);
}

#40 I understand this, and i read this, i just want to confirm this works for Painted textures, not just the placed one in the terraform editor. The two have been treated differently before.