The fastest way of rendering a huuuge model ?
category: general [glöplog]
hcdlt: because it's implementation depends on the driver, and on some of them any calls to drawprimitiveup totally stalls rendering.
btw, zbrush manages huge polycounts with a software renderer too, so it's not that stupid an idea.
navis: that's the way of the scene, people are far more impressed by things they are told to be impressed by ("look ma, 10 million polys") than what actually _is_ impressive :)
navis: that's the way of the scene, people are far more impressed by things they are told to be impressed by ("look ma, 10 million polys") than what actually _is_ impressive :)
smash : zbrush's engine is pretty slow even on 300.000 poly model here. And you can notice it renders simplified version of model while rotating it etc, unless you state you want it the other way.
and these DrawPrimitiveUP issues are news to me, can you recall what card vendor\model had such problems ? ( yes, i know you said .drivers., not card. but if it aint gf3+ or radeon 9600+ then who cares :D )
This is my last effort on this thread:
- It looks as if he wants to do hardware rendering and without lowering at all the resolution or data.
- It looks as if he doesn't want to buy a new 512 mb (or 1 gb) graphic card.
So, obviously, the model should be cut in pieces.
There are 2 possibilities about data sending to vram:
1) The accelerator allows sending data while rendering.
2) The accelerator doesn't allow it.
For any case you should study the way is better, if there are time penalties for starting a data submission or not, etc
Also, about the pieces, it looks as if it would be faster to order the rendering from the data near to the camera to the data far to it. This may be done by software, then, you can use multiple choices for it, from ordering all the vertex to using an octree or whatever. If it is software, the next part to send to the vram could be proccessed in parallel while you are rendering the other part. Also you could use some hardware processing for this ordering, but then you won't be able to paralelize it. So, you have to study all, if it is good or not to order, and then how it should be done.
In any case, the question is a bit senseless without more data. It depends of the hardware you are using. Example: if you has a slow 3d card and a fast computer, the maybe the faster way is software rendering.
So, the best answer I think is: try lots of possibilities and get the faster for the proyect hardware (or one that works good in different configurations), but there is not a "magical solution" that works the faster way in any computer configuration.
:)
- It looks as if he wants to do hardware rendering and without lowering at all the resolution or data.
- It looks as if he doesn't want to buy a new 512 mb (or 1 gb) graphic card.
So, obviously, the model should be cut in pieces.
There are 2 possibilities about data sending to vram:
1) The accelerator allows sending data while rendering.
2) The accelerator doesn't allow it.
For any case you should study the way is better, if there are time penalties for starting a data submission or not, etc
Also, about the pieces, it looks as if it would be faster to order the rendering from the data near to the camera to the data far to it. This may be done by software, then, you can use multiple choices for it, from ordering all the vertex to using an octree or whatever. If it is software, the next part to send to the vram could be proccessed in parallel while you are rendering the other part. Also you could use some hardware processing for this ordering, but then you won't be able to paralelize it. So, you have to study all, if it is good or not to order, and then how it should be done.
In any case, the question is a bit senseless without more data. It depends of the hardware you are using. Example: if you has a slow 3d card and a fast computer, the maybe the faster way is software rendering.
So, the best answer I think is: try lots of possibilities and get the faster for the proyect hardware (or one that works good in different configurations), but there is not a "magical solution" that works the faster way in any computer configuration.
:)
drawPrimitive should be avoided as smash stated in prior post. it's slower and it's driver dependant.
that should be drawPrimitiveUP ;)
The solution to this is the good old Software rendering!
I'll Promise, at least if you have a supercomputer without graphicscard! :D
I'll Promise, at least if you have a supercomputer without graphicscard! :D
"hcdlt: because it's implementation depends on the driver, and on some of them any calls to drawprimitiveup totally stalls rendering."
actually, it's not. the driver never sees dpUP, only the command D3DHAL_DP2DRAWPRIMITIVE2 (and/or it's brothers). it's the d3d-runtime that allocates a buffer in vidmem and fills it. Oh, and btw. the reason for dpUP being slow is just that - buffers allocated and free'd all the time, creating hell in the driver.
actually, it's not. the driver never sees dpUP, only the command D3DHAL_DP2DRAWPRIMITIVE2 (and/or it's brothers). it's the d3d-runtime that allocates a buffer in vidmem and fills it. Oh, and btw. the reason for dpUP being slow is just that - buffers allocated and free'd all the time, creating hell in the driver.
whops, nevermind that. i didn't notice the D3DHALDP2_USERMEMVERTICES flag. ;)