pouët.net

The fastest way of rendering a huuuge model ?

category: general [glöplog]
192 faces glenzvector ?
added on the 2006-02-18 22:09:05 by keops keops
Nearaz:

I hear with ati card its not possible (?)
Anyway i will forward your idea to my friend
who was faced with this dilemma ;-)
added on the 2006-02-19 10:02:27 by magic magic
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...
added on the 2006-02-19 11:01:28 by texel texel
ok what's lod?
added on the 2006-02-19 11:18:37 by skrebbel skrebbel
loughing out detaillevel
added on the 2006-02-19 13:00:33 by the_Ye-Ti the_Ye-Ti
level of detail :(
added on the 2006-02-19 13:01:36 by bzz bzz
uhm or laughing
added on the 2006-02-19 13:03:16 by the_Ye-Ti the_Ye-Ti
Hidden surface removal?
added on the 2006-02-19 20:17:07 by noouch noouch
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.
added on the 2006-02-19 21:20:12 by masterm masterm
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.
added on the 2006-02-19 21:30:54 by apricot apricot
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.
added on the 2006-02-19 21:45:41 by NeARAZ NeARAZ

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 !!!




added on the 2006-02-20 10:26:39 by krabob krabob
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?
added on the 2006-02-20 10:40:56 by psenough psenough
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.<<
added on the 2006-02-20 10:47:10 by krabob krabob
krabob: that will just look ugly. do it on c64 for a real challenge!
added on the 2006-02-20 10:59:21 by psenough psenough

You don't get it !! As a real scener (c) you should know: more polygon look better, no mater the hardware.
added on the 2006-02-20 11:07:31 by krabob krabob
yeah c64 I can imagine, store the polygon on 33 disks, then spend a week with changing disks for one phase \o/.
added on the 2006-02-20 11:09:55 by Oswald Oswald
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.)
added on the 2006-02-20 11:23:19 by smash smash
oh boy. smash believe me i know what both terms mean.
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.
added on the 2006-02-20 11:35:35 by apricot apricot
oh, and don't forget that this polycount without lod is totally pointless because of geometric oversampling.
added on the 2006-02-20 11:38:26 by shiva shiva
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.
added on the 2006-02-20 11:46:31 by apricot apricot
"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...
added on the 2006-02-20 12:05:21 by hcdlt hcdlt
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.)
added on the 2006-02-20 12:49:31 by krabob krabob
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.)
added on the 2006-02-20 13:22:48 by krabob krabob
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.

added on the 2006-02-20 13:25:48 by Navis Navis

login