sio2 wrote:Got it working. My 32x32 test forest (fully textured) runs at 67fps. 128x128 is ~22fps.
A few notes:
1. Your exe (in the zip) crashes for me. I haven't looked why, yet, as I just dumped the new code in my existing project.
2. I'm using the latest SVN and I get the usual compile errors since the prototype of getMaterial() and getMaterialCount() has changed since 1.2 (s32 to u32). Simple enough to solve, but thought I'd mention it for others to know.
3. The snippet gives untextured trees for me. In my demo I added code to set the bark and leaf textures for each tree instance I make.
4. Also, I think both trees are in the same location in the snippet - I'm sure you'll get "I can only see one tree" postings. I set the position of each instance in my demo.
1. Mistake on my part. Had some test code I forgot to remove. You can download it again if you want it to work. Only a minor change in main.cpp.
2. Yes, SVN users will have to convert code themselves. Too much hassle in supporting two versions of Irrlicht.
3+4. The point was to demonstrate how to make two trees use the same meshes and leaves.
Another tip: trilinear on the leaf textures helps. The HW blends between mips and makes things look smoother.
I never paid much attention to texture filtering (I always use the default). I tried the trilinear filter and anisotropic one, but didn't notice much of a difference. Probably my video card's fault, though.
Klasker wrote:3+4. The point was to demonstrate how to make two trees use the same meshes and leaves.
Yep. My only point was that noobs may be scratching their head.
Klasker wrote:I never paid much attention to texture filtering (I always use the default). I tried the trilinear filter and anisotropic one, but didn't notice much of a difference. Probably my video card's fault, though.
I enable 32bpp and mips after I create my device, so mips are created for all the textures - perhaps your textures aren't mipped?
For me, without trilinear the mips "pop" between mip-levels.
The whole thing is great, but the Tree Generator is solid gold. What's the license on it? I was thinking of something along the lines of making some trees and saving them to disk to preprocess them (for some stuff HW instancing and HW point-sprites). I shall call them Klasker Trees, anyway.
sio2 wrote:The whole thing is great, but the Tree Generator is solid gold. What's the license on it? I was thinking of something along the lines of making some trees and saving them to disk to preprocess them (for some stuff HW instancing and HW point-sprites). I shall call them Klasker Trees, anyway.
It is not under any license at the moment (though common laws still apply). I was thinking of putting it under the zlib license, which seems a very reasonable license.
I looked at the Maya camera source, and it seems it doesn't bother to update its absolute matrix properly (no rotation is set). That means the leaves don't know how to render properly. Keeping secrets is a very uncooperative behavior from a scene node, especially from a camera, so I wouldn't recommend using the Maya camera.
The Maya camera is officially incompatible with the leaf billboards.
Klasker damn you do good work. I really like these trees. I hope you licence under zlib or BSD or something
If you want a readme or something with the code and textures just let me know :0
One small bug to report. Rotating the CTreeSceneNode does not rotate the leaves with the trunk
Klasker damn you do good work. I really like these trees. I hope you licence under zlib or BSD or something Smile
If you want a readme or something with the code and textures just let me know :0
One small bug to report. Rotating the CTreeSceneNode does not rotate the leaves with the trunk
the new code in ver 2.1a didn't fix the rotation issue. I am not sure if it is truely a bug in your code or because I have changed things in the prerender/postrender of my local version of irrlicht.
void CBillboardGroupSceneNode::updateBillboards()
{
this->updateAbsolutePosition(); // add this line so billboard group position/rotation is updated before calculations
ICameraSceneNode* camera = SceneManager->getActiveCamera();
if ( !camera )
return;
the new code in ver 2.1a didn't fix the rotation issue. I am not sure if it is truely a bug in your code or because I have changed things in the prerender/postrender of my local version of irrlicht.
Hehe, the absolute matrix being updated at post render rather than pre render is one of Irrlicht's more dreaded features. If your fix works for you then go for it; I'm keeping the code loyal to Irrlicht traditions, though. ISceneNode decides when to update the absolute transformation, and if that happens to be post render, then my trees will use post render.