View Full Version : Non-polygonal technology
I would like to know, what You think about non-polygonal (but not voxel) 3D engines.
darkblu
02-Aug-2002, 14:12
non-polygonal engines or non-poligonal rasterization primitives? an engine may not know what a poly is until the very last moment of passing data for displaying. so narrow down your question, please.
non-polygonal engines or non-poligonal rasterization primitives? an engine may not know what a poly is until the very last moment of passing data for displaying. so narrow down your question, please.
i mean non-polygonal rasterization
darkblu
02-Aug-2002, 16:20
k, i assume you have something along the line of non-tessallated higher-order surfaces in mind. since you asked for an opinion, here's mine: from the view-point of the techology-tempted, i'd embrase anything new which opens unexplored possibilites (ie. unexplored for me). oth, when realism steps in, i believe we're stuck (especially when considering industrial silicon solutions) with polygons for many years ahead. now, if you want to talk theory re native hos rasterizers, i'd gladly join the party :)
Remember that japanese site with some slides which were supposed to come from m$ showing how vertex shaders and pixel shaders would be integrated in DX10? You would think that this would mean scan-conversion would simply be absorbed in the shader program, probably keeping only texture sampling in dedicated hardware ... if this were to happen you would be free to use any sort of surface representation and fragment generation you wanted.
darkblu
02-Aug-2002, 16:56
Remember that japanese site with some slides which were supposed to come from m$ showing how vertex shaders and pixel shaders would be integrated in DX10? You would think that this would mean scan-conversion would simply be absorbed in the shader program, probably keeping only texture sampling in dedicated hardware ... if this were to happen you would be free to use any sort of surface representation and fragment generation you wanted.
that'd be RealCool(tm) to happen, but don't you think than making scan-conversion programmable would violate the notion of pixel pipes' concurrency and thus would take much of contemporary rasterizers' parallelism away?
If it were to happen the shader assembly language would probably have to be explicitly parallel.
Scan conversion will be the very last thing to be programmable.
It's about the only thing in the pipeline that doesn't fit easilly into the stream processing model.
In a lot of ways as polygon sizes converge towards single pixels or less it becomes irrelevant anyway.
Polygons are here to stay, a lot of them might be created in the pipeline rather than explicitly supplied, but I can't see them being replaced any time soon, except in special circumstances i.e. where volumetric representations make sense.
I have created some primitives. (http://ccore.uw.hu/nonpoly.zip)
sorry, but it works only on DOS and Windoze XP
this prog uses the FPU, it is the very first try, but i know how can it be fast.
Scan conversion will be the very last thing to be programmable.
It's about the only thing in the pipeline that doesn't fit easilly into the stream processing model.
In a lot of ways as polygon sizes converge towards single pixels or less it becomes irrelevant anyway.
Polygons are here to stay, a lot of them might be created in the pipeline rather than explicitly supplied, but I can't see them being replaced any time soon, except in special circumstances i.e. where volumetric representations make sense.
Why use polygons when they are smaller than a pixel? I mean we could draw just pixels, and only 800x600 pixels for each frame. We don't need to render the parts which are not visible, do we?
The problem is that when you tessalate higher level primitives, with displacement maps it's difficult to guarantee sizes. So with a target size of say 1/2 a pixel, you might still get polygons that are 1-2 pixels in size, this even happens in the renderman rasteriser. The problem is that the displacement occurs after tessalation.
Polygons are just an easy way to guarantee that you don't end up with holes. and that you end up with the correct subpixel coverage.
Polygons are just an easy way to guarantee that you don't end up with holes. and that you end up with the correct subpixel coverage.
My opinion: Polygons are some kind of linear interpolation, but if you wanna draw curved surfaces, a quadratic interpolation could be better, because you had fewer control points.
At the sizes were talking about, linear interpolation is probably sufficient.
Not everything is a curved surface and most usefull curved surfaces aren't quadratic so you'd still end up with lots of little tiny sub bits.
At the sizes were talking about, linear interpolation is probably sufficient.
Yes, we almost don't need to interpolate when using micropolygon tesselation, but it is slow for real-time engines.
Not everything is a curved surface and most usefull curved surfaces aren't quadratic so you'd still end up with lots of little tiny sub bits.
I mean we could approximate the useful curves with quadratic functions, not with linear ones (like polygons), and that would be better than any degree function - i think.
Well, sorry, but i don't understand sub bits, could you explain them to me, please?
By "sub bits" I was trying to imply the curved equivalent to tessalated polygons.
I'm just unconvinced that in most cases, a quadratic iterator would reduce the geometry load enough to justify the extra complexity.
Yes since a quadratic curve can represent any linear one clearly it can at worst provide the same degree of approximation.
The question is does it substantially reduce the overall polygon count, and at what cost.
There are other issues, which prevent curves from being great rendering primitives, consistent texture mapping, guaranteeing you visit every destination pixel once and don't miss any. They're all soluble, but at greatly increased complexity.
By "sub bits" I was trying to imply the curved equivalent to tessalated polygons.
I'm just unconvinced that in most cases, a quadratic iterator would reduce the geometry load enough to justify the extra complexity.
Yes since a quadratic curve can represent any linear one clearly it can at worst provide the same degree of approximation.
The question is does it substantially reduce the overall polygon count, and at what cost.
There are other issues, which prevent curves from being great rendering primitives, consistent texture mapping, guaranteeing you visit every destination pixel once and don't miss any. They're all soluble, but at greatly increased complexity.
We don't need iterations to draw these surfaces, only some algebric (?sorry for my english?) calculations, i mean you can calculate the z coordinate for every x and y, which guarantees you visit every destination pixel and you don't visit the pixels you don't have to.
Yes, the big problem is texture mapping - which i am thinking of. It can be solved with a (not too accurate) cheat anyway.
The only thing which can make it slow is the square root calculation, it could be hardware accelerated.
But all of these are completely unnecessary if the 10000000 polygon count rendering is fast enough, and i am sure it will be. KyroI and KyroII died too for instance :(. KyroI worked faster with its 25MHz core than the actual Vodoo card - which had 125MHz due to the PowerVR technology, but almost no one was intrested. :(
darkblu
05-Aug-2002, 08:30
We don't need iterations to draw these surfaces, only some algebric (?sorry for my english?) calculations, i mean you can calculate the z coordinate for every x and y, which guarantees you visit every destination pixel and you don't visit the pixels you don't have to.
point is iterative approaches usually give better performance per-pixel as they can make use of any cross-sample recurrencies and still are parallelizable, i.e. prone to parallelization.
Yes, the big problem is texture mapping - which i am thinking of. It can be solved with a (not too accurate) cheat anyway.
The only thing which can make it slow is the square root calculation, it could be hardware accelerated.
i'm curious what cheat did you come up with?
But all of these are completely unnecessary if the 10000000 polygon count rendering is fast enough, and i am sure it will be. KyroI and KyroII died too for instance :(. KyroI worked faster with its 25MHz core than the actual Vodoo card - which had 125MHz due to the PowerVR technology, but almost no one was intrested. :(
i believe you meant powervr1, not kyro1. but the powervr tech relied and still relies on planar properties too, so what did you mean by mentioning them here?
The cheats:
cheat 1: you generate a cube map from the correct texture, but it requires too much memory
cheat 2: you have a floating point zbuffer :D :D
cheat 3: integral calculus (this can be sometimes impossible)
I place some screenshots of my prog here to make you download it :)
http://kep.tar.hu/lgdt/images/pic1147250.png http://kep.tar.hu/lgdt/images/pic1147254.png http://kep.tar.hu/lgdt/images/pic1147255.png http://kep.tar.hu/lgdt/images/pic1147258.png http://kep.tar.hu/lgdt/images/pic1147259.png http://kep.tar.hu/lgdt/images/pic1147262.png http://kep.tar.hu/lgdt/images/pic1147263.png http://kep.tar.hu/lgdt/images/pic1147266.png http://kep.tar.hu/lgdt/images/pic1147271.png
darkblu
05-Aug-2002, 14:34
cheat 1: you generate a cube map from the correct texture, but it requires too much memory
ok, that's a viable cheat.
cheat 2: you have a floating point zbuffer :D :D
but how would you use that for u/v calculations?
cheat 3: integral calculus (this can be sometimes impossible)
now that doesn't sound much as a cheat, does it? more like the real thing.
Hi lgdt
I would love to download your program but it is not available from the link you posted.
Can you email it to me and I can host it on my free webspace for other people to download as well (assumming it is under 4 MB ;) ).
Regards,
misae
Hi lgdt
I would love to download your program but it is not available from the link you posted.
Can you email it to me and I can host it on my free webspace for other people to download as well (assumming it is under 4 MB ;) ).
Regards,
misae
I would love to send it to you if I knew your email address.
I would love to know, why it is not available to you, because it is available to me right now.
Its size is 74 798 bytes.
And thanx for the hosting.
Hi the email address is in the PM i sent you.
Erm scratch the PM message... I still need it as it just wont download from your server.. got stuck at 2.5kb of the download ;)
mormegil
06-Aug-2002, 00:37
I would like to know, what You think about non-polygonal (but not voxel) 3D engines.
An often heard complaint about implicit surfaces and the like is the problem with collision detection. There are surface descriptions (bezier patch for example) that have control points that form conservative convex hulls. These convex hulls could be used for coarse collision detection.
Shadowmaps and stuff like that will be impossible with such surfaces without tesselating and automatic shadowmap extrusion
Simon F
06-Aug-2002, 08:52
Shadowmaps and stuff like that will be impossible with such surfaces without tesselating and automatic shadowmap extrusion
I believe you're thinking of shadow volumes. Shadow maps can handle 'anything' which is why the original shadow map paper "Casting Curved Shadows on Curved Surfaces" (by Lance Williams - Trilinear/MIP mapping inventor) is titled the way it is :-)
mormegil
06-Aug-2002, 09:07
Shadowmaps and stuff like that will be impossible with such surfaces without tesselating and automatic shadowmap extrusion
I believe you're thinking of shadow volumes. Shadow maps can handle 'anything' which is why the original shadow map paper "Casting Curved Shadows on Curved Surfaces" (by Lance Williams - Trilinear/MIP mapping inventor) is titled the way it is :-)
You're absolutely right, i ment shadow volumes! What can I say, it was late :wink:
here (http://www.realtimeraytrace.de)'s a non-poly realtime raytracer!
alexsok
05-Sep-2002, 16:27
Anyone have a link to that Japanese DX10 paper?
vBulletin® v3.8.6, Copyright ©2000-2013, Jelsoft Enterprises Ltd.