Ok, I see. You never talked about a volumetric texture (or any texture at all) so hardly think I could be referring to downsizing the vol. texture.
Funny the article talks about Real Time Simulation of 3D fluids and 2 seconds per frame is not real time.
Reducing the backbuffer's dimensions will greatly improve your performance as the pixel shader is run less.
However, reducing your volumetric texture's size may actually help, because of better cache usage. Just try what's best.
Btw. the technique in that article doesn't render directly to the backbuffer. It applies your raymarching shader to a much smaller offscreen render target and then mix the results with the backbuffer.
Pixel Shader resolution question
Author
Thank you both for suggestions and patience. You were both very helpful.
2 sec per frame is very bad result. Using different volume rendering techniques (slicing) I managed to reach speed of only few milliseconds per frame but they gave very poor quality compared to this method.
Texture is of size about 256[sup]3[/sup]. When number of slices is reduced under 100, there is visible difference in quality.
Texture generation is very fast and there are no problems with that part of problem. Reading it is also fast and reducing texture quality also reduces quality.
Reducing quad size to be the size of smoke bounds did made some difference in speed, but not too much since smoke is taking most of the screen and rays which do not intersect smoke bounding box are discarded.
Reducing the backbuffer size did change speed linearly according to number of pixels.
I wanted to implement some high quality and high speed volumetric rendering technique, but it seams I will have to find some tradeoff between quality and speed
Ty again,
Lisur
2 sec per frame is very bad result. Using different volume rendering techniques (slicing) I managed to reach speed of only few milliseconds per frame but they gave very poor quality compared to this method.
Texture is of size about 256[sup]3[/sup]. When number of slices is reduced under 100, there is visible difference in quality.
Texture generation is very fast and there are no problems with that part of problem. Reading it is also fast and reducing texture quality also reduces quality.
Reducing quad size to be the size of smoke bounds did made some difference in speed, but not too much since smoke is taking most of the screen and rays which do not intersect smoke bounding box are discarded.
Reducing the backbuffer size did change speed linearly according to number of pixels.
I wanted to implement some high quality and high speed volumetric rendering technique, but it seams I will have to find some tradeoff between quality and speed
Ty again,
Lisur
Thank you both for suggestions and patience. You were both very helpful.
2 sec per frame is very bad result. Using different volume rendering techniques (slicing) I managed to reach speed of only few milliseconds per frame but they gave very poor quality compared to this method.
Texture is of size about 256[sup]3[/sup]. When number of slices is reduced under 100, there is visible difference in quality.
Texture generation is very fast and there are no problems with that part of problem. Reading it is also fast and reducing texture quality also reduces quality.
Reducing quad size to be the size of smoke bounds did made some difference in speed, but not too much since smoke is taking most of the screen and rays which do not intersect smoke bounding box are discarded.
Reducing the backbuffer size did change speed linearly according to number of pixels.
I wanted to implement some high quality and high speed volumetric rendering technique, but it seams I will have to find some tradeoff between quality and speed
Ty again,
Lisur
Yeah this is the drawback of using NVidia samples, they aren't created in a general solution to the problem. Their solutions often only work in the context they use them in.
You might be better of running your fluid simulation in a DirectCompute or CUDA kernel and only render the results form that simulation. I have seen this in real time and it looks pretty good.
2 sec per frame is very bad result. Using different volume rendering techniques (slicing) I managed to reach speed of only few milliseconds per frame but they gave very poor quality compared to this method.
Slicing is generally how it's done. As for quality, it depends a lot on how you place those slices (and how many of them). It's not my strongest point, but AFAIK there are algorithms for determining the optimal slice position & orientation.
This seems to be one of the few cases that dynamic branching might actually help out. You could read the pixel position system value, and then determine if you should calculate that pixel based on some criteria. That would let you do a stipple pattern across your full screen quad, and thus reduce the number of times you perform your calculations (as opposed to the number of times your shader is invoked).
Also, if you can swing an upgrade to D3D11, DirectCompute would be a perfect match for this application!
Also, if you can swing an upgrade to D3D11, DirectCompute would be a perfect match for this application!
Author
I deeply studied the problem and run some test and here's what I got:
I used stencil buffer to project grid sides on near clipping plane so pixel shader routine is never called on a point whose ray does not intersect smoke. With that, I reached 500 ms per frame (speedup 4x).
Funny thing happened. When I reduce backbuffer width/length, timing is the same.
Another thing which is suspicious to me is my CPU usage. One of CPU cores goes up to 90% when pixel shader is executed (when I use slices CPU usage is very low).
Is there a chance that Direct3D actually emulates my PS routine on CPU? How can I check that?
Thanks,
Lisur
I used stencil buffer to project grid sides on near clipping plane so pixel shader routine is never called on a point whose ray does not intersect smoke. With that, I reached 500 ms per frame (speedup 4x).
Funny thing happened. When I reduce backbuffer width/length, timing is the same.
Another thing which is suspicious to me is my CPU usage. One of CPU cores goes up to 90% when pixel shader is executed (when I use slices CPU usage is very low).
Is there a chance that Direct3D actually emulates my PS routine on CPU? How can I check that?
Thanks,
Lisur
Author
Just to inform you that I found a solution 
I was compiling PS on every frame so compilation time took a lot of time. That was the reason CPU usage was high.
Now I can run my program with 20-30 FPS w/o reduction of backbuffer or texture size which could be treated as real-time
Ty all guys again
I was compiling PS on every frame so compilation time took a lot of time. That was the reason CPU usage was high.
Now I can run my program with 20-30 FPS w/o reduction of backbuffer or texture size which could be treated as real-time
Ty all guys again
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
