Lonesome Ducky wrote:Ok, here's the updated code. It doesn't completely get rid of black lines, but it makes them far less noticeable. I think the black lines are inevitable with a texture atlas.
It being cut off is because your camera doesn't have a high enough far value I think. But from what's visible, it seems to look much better. Try messing with the lodbias value it sets for the material too to prevent it from looking so sharp.
Lonesome Ducky wrote:It being cut off is because your camera doesn't have a high enough far value I think. But from what's visible, it seems to look much better. Try messing with the lodbias value it sets for the material too to prevent it from looking so sharp.
It doesn't look better at all when in motion, If I move cam it looks like its a TV noise effect just in more colors, and as I said the fps is a lot lower
The fact that it's so sharp is an effect of the LODBias change. Find it in the combine code and either delete it or make it a smaller value. As for not using a texture atlas, it's not really an option Without it, I'd have to switch textures on the graphics card and could not batch the meshes, defeating the speedup of the class.
Hmm, beyond that the code shouldn't be doing anything to make the texture look so sharp. Could you perhaps try it with the original test project and see if it causes the same problem? Here's what it looks like for me: http://i117.photobucket.com/albums/o73/Azail/view.png
Tried with all renderers and I can't reproduce the effect you're having.
first of all: nice project, gives a real performance boost in my case. I tried to integrate it into my RandomForestGenerator demo project yesterday, and it shifts the framerate from 13 to about 180 by combining 1010 trees into 1 mesh. I just have a Z-Buffer problem (I guess). Here's an image:
The trees are all about equal in size, and they are shown in the wrong order. OK, the image doesn't show the problem that well, so I uploaded a zip file to show the problem:
shouldn't this be a Material problem? certain materials requires Z sorting of nodes before rendering. I think it will work correctly only using meshes wich have just the same material with different textures. And will not work for materials that requires Z sorting.
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
Use the ALPHA_REF material for leaves, otherwise you will get these problems. Meshes are not sorted internally, so rendering in the wrong order can happen in huge meshes.
hybrid wrote:Use the ALPHA_REF material for leaves, otherwise you will get these problems. Meshes are not sorted internally, so rendering in the wrong order can happen in huge meshes.
That change fixed it. I'm still impressed with the performance boost, I have updated my RandomForest plugin demo. I hope it's OK that I included the snippet in the code and download version.
Now I think I'll go my "normal way": wrap this code up in a scene node and create a plugin for IrrEdit. I prefer to have as much as possible configurable from the editor instead of the actual code.
A month later, sure! It's no problem to use it in your code download. I wrote this code to help people, not for recognition; so if it helps you help people, that's even better!
Lonesome Ducky wrote:A month later, sure! It's no problem to use it in your code download. I wrote this code to help people, not for recognition; so if it helps you help people, that's even better!
Heh, I made my own combiner using your's just that mines doesn't use texture atlas and thus I don't have any more of those mip map glitches
).
Without it, I'd have to switch textures on the graphics card and could not batch the meshes, defeating the speedup of the class.
