The fastest way of rendering a huuuge model ?
category: general [glöplog]
192 faces glenzvector ?
Nearaz:
I hear with ati card its not possible (?)
Anyway i will forward your idea to my friend
who was faced with this dilemma ;-)
I hear with ati card its not possible (?)
Anyway i will forward your idea to my friend
who was faced with this dilemma ;-)
I suppose the problem is sending data to vram wich is slow. You can cut the model in parts and render using the same zbuffer. Then, if you don't need interactive visualization, just animation, you could reduce the time sending data by rendering more than one frame with each part...
ok what's lod?
loughing out detaillevel
level of detail :(
uhm or laughing
Hidden surface removal?
I don't think any existing gfx card could render 3M vertices in real time. So if real-time animation can't be done I think it's good idea to raytrace it instead of using rasterization.
Quote:
or LOD?
Quote:
Hidden surface removal?
Quote:
Hidden surface removal?
Quote:
an octree?
guys read my posts carefully, i explain why this is not a solution in this very case.
even if it was a solution, the question is
what is the fastest way of rendering a model if it doesn't fit into VRAM. leaving model intact.
yes, this means no LOD.
mastern: you're completely wrong. even quite old video cards have no problems (except fitting into RAM) at rendering a single model of several million polys.
fadeout: split the model into chunks, and either pump via dynamic buffers, or just use managed buffers and let D3D handle the thing. I'm not sure which would be faster.
fadeout: split the model into chunks, and either pump via dynamic buffers, or just use managed buffers and let D3D handle the thing. I'm not sure which would be faster.
Quote:
3Million vertices,[...] it's precision what is appreciated in the project, exact model must be rendered. that's the point.
pfff ! clueless ! Laughable ! Hey look I can do BILLIARDDZZ TRIANGLES !! WORLD RECORD !!! there are over 10 triangles BY PIXEL !!! MINE'S bIGGER ! >>MORE IS BETTER<< ONLY TRUE SCENERS CAN COUNT
TRIANGLES !!! LOW POLY OBJECTS ARE GAY !!!
fadeout: by reading your posts carefully we can deduct that the fastest way is obviously to software render it since it, intact, doesnt fit into the VRAM. do i win a bicycle?
additional ideas:
- force the more low resolution (Ie: 320x200 pixel screens, like true demosceners are used to.). It will free video memory, and you will be able to add >>MORE VERTICES<< ;-)
- force a 256 color display. thus, it has been prooved for long by REAL SCENERS that a 8bit pixelformat can take something like ** 4 TIMES LESS VIDEO MEMORY ** as a 32 bit loosy RGBA pixelformat. Then you will notice that NOT ONLY it frees memory for... MORE VERTICES, but it also SPEED UP THE CACHES, leading to MORE SPEED. MORE SPEED->MORE VERTICES-> MORE POLYGON ->BINGO BINGO.
- disable texture rendering, WHAT THE FUCK ?? it is a * fault * to believe texture rendering brings more * >>appreciated precision. <<*. Only polygons can do that. The real sceners human eyes, that god created and put in the middle of the face of true sceners, sure, can make the difference.
- (and now trick of the trick , fasten you belt)-> use flat rendering. When you have a so WORLDZRECORDLIKE engine, number of polygons are under the number of suxxor pixels. So, there is no more need for any kind of lame shading: use one flat color, disable lights, (of course), it will also allow you to add more polygon... because once again, right, MORE IS BETTER.
- don't hesitate a single seconds to ADD MORE POLYGONS. because >>It's appreciated.<<
- force the more low resolution (Ie: 320x200 pixel screens, like true demosceners are used to.). It will free video memory, and you will be able to add >>MORE VERTICES<< ;-)
- force a 256 color display. thus, it has been prooved for long by REAL SCENERS that a 8bit pixelformat can take something like ** 4 TIMES LESS VIDEO MEMORY ** as a 32 bit loosy RGBA pixelformat. Then you will notice that NOT ONLY it frees memory for... MORE VERTICES, but it also SPEED UP THE CACHES, leading to MORE SPEED. MORE SPEED->MORE VERTICES-> MORE POLYGON ->BINGO BINGO.
- disable texture rendering, WHAT THE FUCK ?? it is a * fault * to believe texture rendering brings more * >>appreciated precision. <<*. Only polygons can do that. The real sceners human eyes, that god created and put in the middle of the face of true sceners, sure, can make the difference.
- (and now trick of the trick , fasten you belt)-> use flat rendering. When you have a so WORLDZRECORDLIKE engine, number of polygons are under the number of suxxor pixels. So, there is no more need for any kind of lame shading: use one flat color, disable lights, (of course), it will also allow you to add more polygon... because once again, right, MORE IS BETTER.
- don't hesitate a single seconds to ADD MORE POLYGONS. because >>It's appreciated.<<
krabob: that will just look ugly. do it on c64 for a real challenge!
You don't get it !! As a real scener (c) you should know: more polygon look better, no mater the hardware.
yeah c64 I can imagine, store the polygon on 33 disks, then spend a week with changing disks for one phase \o/.
fadeout: octree != lod.
as nearaz says, it's more than possible to render it in realtime.
split the model into chunks, put the chunks in an octree and hope to lose some of them by occlusion or frustum culling. (unless the model is one big alphablend fest or something, it's unlikely that some part of it wont be obscured by other parts at some point and then you can get rid of it for that frame.)
then supply to the card using dynamic vbs, which is probably more efficient than managed. (use d3dlock_discard.)
some other advice: sort and render from front to back and save yourself some fillrate.
never ever ever ever use drawprimitiveup or the variants of it. ever. even for like 4 vertices.
generate tristrips from the model and hopefully cut your indexbuffer size (or even remove the need for them totally if it's smaller.)
as nearaz says, it's more than possible to render it in realtime.
split the model into chunks, put the chunks in an octree and hope to lose some of them by occlusion or frustum culling. (unless the model is one big alphablend fest or something, it's unlikely that some part of it wont be obscured by other parts at some point and then you can get rid of it for that frame.)
then supply to the card using dynamic vbs, which is probably more efficient than managed. (use d3dlock_discard.)
some other advice: sort and render from front to back and save yourself some fillrate.
never ever ever ever use drawprimitiveup or the variants of it. ever. even for like 4 vertices.
generate tristrips from the model and hopefully cut your indexbuffer size (or even remove the need for them totally if it's smaller.)
oh boy. smash believe me i know what both terms mean.
as i said on the previous page
which meant any types of tree-based clipping.
Allright. thanks to NeARAZ for useful advice.
Now all the megaelite clueful guys may continue flooding this thread. i wash my hands.
as i said on the previous page
Quote:
BSP trees and such do not really do the trick in this very case...
which meant any types of tree-based clipping.
Allright. thanks to NeARAZ for useful advice.
Now all the megaelite clueful guys may continue flooding this thread. i wash my hands.
oh, and don't forget that this polycount without lod is totally pointless because of geometric oversampling.
allright i got the details, it's not a 3d-scanner output rendering, but an algorithm similar to "The randomized z-buffer algorithm", there was a paper on it somewhere.
So these 3 millions polys are a leftover of a really huge model, and they are the result of octree-based clipping. Theoretical figures show that this is somewhat minimal amount of polys for a reliable scene representation.
that's it. i'm off.
So these 3 millions polys are a leftover of a really huge model, and they are the result of octree-based clipping. Theoretical figures show that this is somewhat minimal amount of polys for a reliable scene representation.
that's it. i'm off.
"never ever ever ever use drawprimitiveup or the variants of it. ever. even for like 4 vertices."
why? if i had a vertex buffer in which data changes at runtime (for example with skeletal animation), drawprimitiveup is my choice...
why? if i had a vertex buffer in which data changes at runtime (for example with skeletal animation), drawprimitiveup is my choice...
OK, I stop trolling. Actually, I was about to deliver one or other trick, but it has been done and done already before, so I tried to make you focus on the simple fact that having big objects just for having a big object might be ridiculous. So now, a serious question: could we just have a look at the dicussed object, I'm curious about it: knowing the general shape of it could help. One optimization method could then apply or not. ( .... and sorry, but if it is a 3 Million polygon "torus", i will laugh my ass for 3 weeks.)
as i'm about it: (sorry again) my previous trollpost is not that mockish, and it is based on a real effect: remember the " big yellow fly" on that nooon demo ( no! or "stars", I don't remember). They rendered a big object with many polygons for that time, and actually the trick was:
-no goureau, but 1 color per poly: you couldn't see the difference because the poly were small.
-no rotation: only add and no muls on the matrix. well, no one just did fucking notice.
(and probably: no Z buffer, no sorting,...)
(advice to fakers that would do that again: don't let the effect too much times and add stupid texts, just so that the watcher just can't concentrate on how it is done.)
-no goureau, but 1 color per poly: you couldn't see the difference because the poly were small.
-no rotation: only add and no muls on the matrix. well, no one just did fucking notice.
(and probably: no Z buffer, no sorting,...)
(advice to fakers that would do that again: don't let the effect too much times and add stupid texts, just so that the watcher just can't concentrate on how it is done.)
I think that the fly in stars was (maybe) all this plus an OVERestimation of polygons (the number displayed was probably like 10 times as many as they really were) plus maybe sprites for parts of the fly like the antennas.
