Tree It
So Tree It has received some updates as of late to which mainly focused on the two new additions that I mentioned within the last update thread, which was a mesh system and splitting of trunk/branches. I was unable to add a leaf mesh editor (for custom leaf shapes for better alpha testing), I will most likely have to create a separate program for this and I just don't have the time to do this now. Some other features have been added such as PBR and selection, you can view the full list of the changes here.
Unfortunately the update did break quiet few things such as changes to the save format so older tree saves will no longer work, So if you still need the older version of treeit you can still download the zip from here TreeItold.zip.
I would like to add one more thing, Im getting a lot of emails regarding to licence agreement and I have now started to ignore or not reply to them which I must apologize for. I would like to state, tree it is free and you can do as you wish with the tree model exports. I would however like the actual program to not be redistributed by any other website/domain.
Although I will not be returning to tree it for quite some time, there are still some features I would like to add to the tool.
Future improvements
Roots - The old root sytem has been removed to make way for a potentially better system that will hopefully seamlessly blend with the trunks vertices.
Start Sides/end sides - This will act as an additional poly reduction for trunk and branches by reducing the number of sides at every other segment.
Vertex displacer - This will be a spherical brush that will allow displacement of vertices along the surface normal or view normal.
Curvature graphs - This will add much more control over most parameters such as length and positioning, this will also help remove a lot of UI clutter where there are multiple variables that control a single parameter (such as length).
Advanced lighting
Progress on the ALS has been so slow as I keep encountering problems with it. I really would like to get what Im currently working on done so I can get back to working on mapscape but I have been making some progress with it as of late.
Shadow mapping
So the way in which shadow mapping works has changed, I did try to implment EVSM but this technique has crippling bugs that I could not live with. Originally I was using shadow masks, where shadow mapping results are drawn out to a separte full screen render target ready to be blurred in screen space (the intention here was to then apply a bilateral guessing blur). However this method dose have some performance implications as we are dealing with an additional full screen render target. Im now using a more conventional solution where shadows are filtered in disk patten with a weighted 2x2 PCF applied at each sample (essentially creates a bilinear filterd shadow map lookup). The issue now is banding between shadow samples, which I am using a random noise value each frame in a bid to eliminate this. Shadow map caching has also been added to try and boost performance by only rendering whats dynamic when the casting light is static.
Screen space reflections
I personally find screen space reflections god awful and Im not to sure why I ended up adding them in, They cost a lot to render and produces numerous errors. But most games tend to use this technique as a way to produce "cheap" real time reflections, I normally just turn them off but they can add some additional quality when used correctly.
Batching
So Ive added batching to the ALS in an attempt to improve performance by reducing the number of draw calls. I started by batching spot/point lights into groups of 25, so for every 25 in screen spot light will act as a single draw call. This also reduced the number of shaders needed, as before each light was a single object with a unique shader effect. So in essence 100 lights would require 100 shaders to be loaded and compiled as well consuming 100 draw calls. Where as now its only 4 shaders and 4 objects which is a big improvement. I have also added an object batching system, but is still in need of bit more work done to it.
Wip
Terrain meshes
So I do have terrain meshes working, but Im experiencing some performance related issues with them. The system is using 16x16 randomly placed plains clumped together into groups of 8x8 batches (16384 plains in total). These are then assigned to the terrain surface using vertex texture lookup.
Overdraw/performance related issues
So I have some performance related issues when it comes to the terrain mesh system. But this will also effect other areas where there are a lot alpha tested objects such as the rendering of tree models which can contribute to overdraw. This will effectively means the pixel shader is run over and over again resulting hundreds of texture lookups and pixel shader instructions. Not only that but the Gbuffer then has to be written to over and over again, which is where the biggest performance impact lies. Depth sorting the rendering of objects front to back will solve this for the most part thanks to internal early z rejection But I cannot z sort individual leaves on tree object or individual grass plains used as terrain meshes. I will work on a simple z sort algorithm for the batching system, but Im not sure if DBp has an option to z sort individual objects front to back. If not I will see if I can somehow do it myself by swapping object IDs, as far as I know DBp renders objects in groups based on texture order with the lowest applied image ID first then object ID.
If I'm not able to sort the rendering front to back, I have done some on the side tests mostly with trying depth pre-pass. This is actually not that complex to do and will be really esay to add in. It dose improve frame rate, but will only benefit objects with extreme amounts depth complexity with alpha testing (such terrain grass meshes and tree objects ect). This however will not fully fix overdraw, as objects now have to be drawn twice.
Here a test image with a single mesh with 16k random grass plains.
As you can see my frame rate does almost double here with Z pre-pass enabled but is still not fast enough, especially in comparison to forward rendering with no Gbuffer to write to.
for those who may be interested, this is what the shader technique for z prepass looks like which requires a simple render state change with 2 passes. With the first pass being very simple, and used only to fill the zbuffer. Early z rejection on the second pass prevents the fragment shader from running and writing to the Gbuffer = profit.
So Tree It has received some updates as of late to which mainly focused on the two new additions that I mentioned within the last update thread, which was a mesh system and splitting of trunk/branches. I was unable to add a leaf mesh editor (for custom leaf shapes for better alpha testing), I will most likely have to create a separate program for this and I just don't have the time to do this now. Some other features have been added such as PBR and selection, you can view the full list of the changes here.
Unfortunately the update did break quiet few things such as changes to the save format so older tree saves will no longer work, So if you still need the older version of treeit you can still download the zip from here TreeItold.zip.
I would like to add one more thing, Im getting a lot of emails regarding to licence agreement and I have now started to ignore or not reply to them which I must apologize for. I would like to state, tree it is free and you can do as you wish with the tree model exports. I would however like the actual program to not be redistributed by any other website/domain.
Although I will not be returning to tree it for quite some time, there are still some features I would like to add to the tool.
Future improvements
Roots - The old root sytem has been removed to make way for a potentially better system that will hopefully seamlessly blend with the trunks vertices.
Start Sides/end sides - This will act as an additional poly reduction for trunk and branches by reducing the number of sides at every other segment.
Vertex displacer - This will be a spherical brush that will allow displacement of vertices along the surface normal or view normal.
Curvature graphs - This will add much more control over most parameters such as length and positioning, this will also help remove a lot of UI clutter where there are multiple variables that control a single parameter (such as length).
Advanced lighting
Progress on the ALS has been so slow as I keep encountering problems with it. I really would like to get what Im currently working on done so I can get back to working on mapscape but I have been making some progress with it as of late.
Shadow mapping
So the way in which shadow mapping works has changed, I did try to implment EVSM but this technique has crippling bugs that I could not live with. Originally I was using shadow masks, where shadow mapping results are drawn out to a separte full screen render target ready to be blurred in screen space (the intention here was to then apply a bilateral guessing blur). However this method dose have some performance implications as we are dealing with an additional full screen render target. Im now using a more conventional solution where shadows are filtered in disk patten with a weighted 2x2 PCF applied at each sample (essentially creates a bilinear filterd shadow map lookup). The issue now is banding between shadow samples, which I am using a random noise value each frame in a bid to eliminate this. Shadow map caching has also been added to try and boost performance by only rendering whats dynamic when the casting light is static.
Screen space reflections
I personally find screen space reflections god awful and Im not to sure why I ended up adding them in, They cost a lot to render and produces numerous errors. But most games tend to use this technique as a way to produce "cheap" real time reflections, I normally just turn them off but they can add some additional quality when used correctly.
Batching
So Ive added batching to the ALS in an attempt to improve performance by reducing the number of draw calls. I started by batching spot/point lights into groups of 25, so for every 25 in screen spot light will act as a single draw call. This also reduced the number of shaders needed, as before each light was a single object with a unique shader effect. So in essence 100 lights would require 100 shaders to be loaded and compiled as well consuming 100 draw calls. Where as now its only 4 shaders and 4 objects which is a big improvement. I have also added an object batching system, but is still in need of bit more work done to it.
Wip
Terrain meshes
So I do have terrain meshes working, but Im experiencing some performance related issues with them. The system is using 16x16 randomly placed plains clumped together into groups of 8x8 batches (16384 plains in total). These are then assigned to the terrain surface using vertex texture lookup.
Overdraw/performance related issues
So I have some performance related issues when it comes to the terrain mesh system. But this will also effect other areas where there are a lot alpha tested objects such as the rendering of tree models which can contribute to overdraw. This will effectively means the pixel shader is run over and over again resulting hundreds of texture lookups and pixel shader instructions. Not only that but the Gbuffer then has to be written to over and over again, which is where the biggest performance impact lies. Depth sorting the rendering of objects front to back will solve this for the most part thanks to internal early z rejection But I cannot z sort individual leaves on tree object or individual grass plains used as terrain meshes. I will work on a simple z sort algorithm for the batching system, but Im not sure if DBp has an option to z sort individual objects front to back. If not I will see if I can somehow do it myself by swapping object IDs, as far as I know DBp renders objects in groups based on texture order with the lowest applied image ID first then object ID.
If I'm not able to sort the rendering front to back, I have done some on the side tests mostly with trying depth pre-pass. This is actually not that complex to do and will be really esay to add in. It dose improve frame rate, but will only benefit objects with extreme amounts depth complexity with alpha testing (such terrain grass meshes and tree objects ect). This however will not fully fix overdraw, as objects now have to be drawn twice.
Here a test image with a single mesh with 16k random grass plains.
As you can see my frame rate does almost double here with Z pre-pass enabled but is still not fast enough, especially in comparison to forward rendering with no Gbuffer to write to.
for those who may be interested, this is what the shader technique for z prepass looks like which requires a simple render state change with 2 passes. With the first pass being very simple, and used only to fill the zbuffer. Early z rejection on the second pass prevents the fragment shader from running and writing to the Gbuffer = profit.
- Code: Select all
technique Geometry
{
pass p1
{
vertexShader = compile vs_3_0 VS();
pixelShader = null;
Sampler[0]=<Base>;
AlphaOp[0]=MODULATE;
AlphaArg1[0]=TEXTURE;
CullMode=none;
zwriteEnable=true;
ZFunc=less;
ColorWriteEnable=0;
ColorWriteEnable1=0;
ColorWriteEnable2=0;
ColorWriteEnable3=0;
AlphaBlendEnable=false;
AlphaFunc=greater;
AlphaTestEnable=true;
AlphaRef=64;
}
pass p2
{
pixelShader = compile ps_3_0 PS();
CullMode=none;
zwriteEnable=false;
ZFunc=equal;
ColorWriteEnable=3;
ColorWriteEnable1=3;
ColorWriteEnable2=15;
ColorWriteEnable3=15;
AlphaBlendEnable=false;
AlphaTestEnable=false;
}
}