PDA

View Full Version : fR gets rid of polygons


sykosys
12-12-2003, 04:17 PM
http://www.cebas.de/products/images/fr_stage1/scanfluid_web.jpg


This image was created by Scanline Production GmbH. Their R&D department used finalRender Stage-1, along with the advanced SDK, to implement a new Object Type called ISO-Surface. This new object type does not need a fixed set of triangles or polygons to describe a surface of an object. The raytracer's rays directly intersects the surface, which is generated through formulae, without creating a single triangle.

The latest product under development at SCANLINE with the codename "SCANfluid", simulates complex liquids that can realistically interact with their environment.
====

http://www.finalrender.com/index.asp?UD=10-7888-35-788

According to Edwin Braun, in an IRC chat, "we plan to offer such a object, however we do not know right now how and when. There are mutliple options for that... we could directly render BSplines for example..."

More on isosurfaces;
http://www.ems-i.com/gmshelp/Data_Sets/Iso-Surfaces.htm

arctor
12-12-2003, 06:44 PM
if you want to play with iso surfaces right now, just download the Apprentice version of Houdini - it has an ISO-Surface SOP

Garma
12-12-2003, 07:03 PM
sounds cool... My guess it's slow as hell though...

sykosys
12-12-2003, 07:29 PM
Originally posted by Garma
sounds cool... My guess it's slow as hell though...

Apparently, the neatest thing about it is that it's almost real-time...

MCronin
12-12-2003, 07:34 PM
POV Ray also supports ISO Surfaces if I'm not mistaken.

It's not slow, well not in Houdini at least, but most people aren't going to find it particularly useful either. ISO Surfaces have been around for a long time but their use is pretty limited which is why most softwares don't implement them. The ISO Surface is a 3D visualization of a mathematical function and you can make some pretty cool looking abstract art with them, also, Houdini lets you use 3D textures to generate an ISO Surface, which is great for creating gaseous objects.

Some examples including their functions in POV Ray here. The functions should also work in Houdini with the correct syntax.

http://members.jcom.home.ne.jp/tom3d/pov37/ilpov37e.htm

Per-Anders
12-12-2003, 07:36 PM
ok, can someone explain to me in basic terms more the difference between this and NURBS rendering and the difference between what this is doing and what happens in PRMAN and REYES (which is also meant to be sooo fast).

playmesumch00ns
12-12-2003, 08:55 PM
Isosurfaces are the product of a series of equations.

NURBS surfaces and other parametric surfaces are the product of a series of equations (blending functions) specified in terms of control points.

REYES renderers dice any surface be it a polygon, NURBS, blobby, curve, whatever, into little grids of micropolygons (basically tiny little quads) and operates on those, whereas it sounds like this is intersecting rays directly with the isosurfce. Which, unless Cebas can prove otherwise, is pretty useless for 99% of applications.

Dearmad
12-12-2003, 08:56 PM
Wow, iso surfaces as news. These have been around forever- they're just slow and the math behind describing a very complex objects is not simple enough for any user beyond a physicist of mathematician to use.

Sheesh next they'll anounce four dimensional isos... ooooh...:rolleyes: animated surfaces anyone?

Thalaxis
12-12-2003, 10:18 PM
The main advantage AFAIK in not tesselating to polys to render is
essentially resolution independence. By not tesselating, you get
the benefits of inifinite detail levels without worrying about a
higher subdivision count, or higher NURBS resolution or something
like that.

The obvious downside of course is overhead; computing ray
intersections with implicit surfaces is computationally more
difficult than with polys. RealSoft for example uses a modified
version of Newton's Method to do this. How they got any sort of
speed out of that I have no idea, but it's no slouch (unless you
compare it to Cinema or something ;)).

Still... I can see some benefits in some areas, like if you want to
create ultra-detailed landscapes like MojoWorld's. The amount of
geometry that MojoWorld generates is staggering (an earth-sized
plant at 1 meter resolution, eh?), and yet MojoWorld files are
miniscule... because it's all computed on the fly.

Is there a compelling reason to be able to render without
tesselation? I don't know. I wish I did... but I would theorize that
there might be some benefits for some types of visulization tasks,
and maybe for accomplishing the sorts of things that RealFlow
does with water surfaces.

Self-Designer
12-13-2003, 12:08 PM
Mmm... If someone will find a general way of converting a mesh to a formula (like JPEG takes a row of pixels and build it by sinuses and such as much as i know) - He will be able to develop a resolution-free modeling program - like working with clay or something... anf if it's really fast as sykosys said... then neat!

Think about that - polygons are very limited - You can't extract whatever u want - u have to build it's edges on the surface for that, u always have to save as lower as u can the polygons-count, boolean is an headache, when things gets complicated it can be really a mess... Think about a life without polygons... :drool: - Just start with a primitive like a sphere, and then push here, pull there...

Does it help with the UVW mapping? I never worked with Nurbs... I know there is a great mess with polygons... mmm...

kemijo
12-13-2003, 05:05 PM
Depending on what renderer you are using, NURBS and Subdivs are already resolution independant at render time, and they were designed to be. Maya tesselates both of these before rendering, but prman doesn't, for example - they are rendered as true smooth curved surfaces. Of course you still have a sort of 'resolution' of the surface in the modeler, which would be the poly cage count or NURBS isoparm or patch number.

sykosys
12-13-2003, 05:23 PM
Keeping in mind the aforementioned ISO Surfaces are still beta, and this was only meant as a technology preview...

Edwin tells me that the image was rendered at 1K resolution in 10 minutes, on a single processor machine. (He doesn't know exact specs, but a p4 2.xx is suspected.)

As far as creation/useabilty speed, the system is "top secret", but it's apparently very, very fast....

... but we'll just have to wait and see, of course. Proof in the pudding, and all that...

Marc Andreoli
12-13-2003, 05:32 PM
Originally posted by kemijo
Maya tesselates both of these before rendering, but prman doesn't, for example - they are rendered as true smooth curved surfaces.

actually, prman converts all surfaces to polygons during rendering, too. They are called 'micro polygons' (smaller than a pixel), you never really see them, it is just an internal thing... but it is one of the reasons you still need tons of ram when using displacement shaders and you cannot subdivide the screen into small blocks because the displacements would get clipped from one block to the next.

Self-Designer
12-13-2003, 06:02 PM
As much as i see it, it let u free from nurbs' isoparm, mesh's polygons and stuff if it will finally work as i suggested. In my vision, u'r not aware of the components which build the object, how it's build etc. U just work on the surface, push here, pull there, mark a shape on the surface and extrude it... The program will do the calculations to find the right formula for your model.

image was rendered at 1K resolution in 10 minutes - 10 minutes is alot of time to 1,000 pixels... or did i understand it wrong?

MCronin
12-13-2003, 06:32 PM
Originally posted by Marc Andreoli
actually, prman converts all surfaces to polygons during rendering, too. They are called 'micro polygons' (smaller than a pixel), you never really see them, it is just an internal thing... but it is one of the reasons you still need tons of ram when using displacement shaders and you cannot subdivide the screen into small blocks because the displacements would get clipped from one block to the next.


The way parametric surfaces are treated in PRMan or Mantra is different than other renderers. When PRMan "tesselates" an object into micropolygons it's an entirely different concept than the way these other renderers tesselate a curved surface. In Maya or Max's renderer, you give it a NURBS sphere, the software then tesselates the sphere to triangles and then clips it and renders it. With PRMan, it takes the NURBS sphere directly as a parametric surface, clips it, and then in the process of rendering generates X polygons per pixel based on the defined shading rate on a per object basis.

The reason why it's said that these surfaces in PRMan or Mantra are resolution independent while in other renderers they are not is because of the above. In Max or Maya if you move you camera closer to your displaced NURBS surface, eventually you are going to see faceting and have to increase the tesselation. To get a good displacement you are going to have to create a lot of extra geometry. In PRMan and Mantra, since the object is handled as a parametric surface and tesselated at the pixel level during rendering, no matter how close you move the camera in you will not see any faceting provided your shading rate is set to generate at least one polygon per pixel (the default). The resources required to do a displacement in PRMan should be significantly less than in an equivalent scene in a renderer like Max's or Maya's because it has less geometry to cull and set up for rendering.

Iso Surfaces unlike other surfaces, which are defined by a collection of points, are instead described by an equation. When dealing with Iso Surfaces you supply the bounds for a cubic volume, and an equation that uses X,Y and Z terms. The equation works it's way through the volume using the X, Y, and Z coordinates in the volume as terms in the equation. Anywhere the equation evaluates a change between positive and negative, a surface is drawn. If you've ever graphed a slope in Algebra, or used an animation curve editor, you should grasp this. It's the same concept, except in three dimensions. Because of this, Iso Surfaces are also resolution independent. If you specify an Iso Surface in a 2 unit cube using -1 and 1 for the min and max X,Y,Z bounds, there are an inifite number of points contained within the volume. Your renderer doesn't, however, need to evalaute every possible set of coordinates within the volume. It will instead evaluate the volume based on what the camera sees and the resolution of your image, and draw only the necessary pixels.

MCronin
12-13-2003, 06:40 PM
...

sykosys
12-13-2003, 06:43 PM
Originally posted by Artist 3D
- 10 minutes is alot of time to 1,000 pixels... or did i understand it wrong?

I imagine the original was 1024X768. As I said, it's beta/technology test, and really hasn't been optimized yet. Further, there's some serious caustics happening there, along with reflections/refractions, which probably obscure the actual "speed" of the ISO surfaces.

Marc Andreoli
12-13-2003, 11:04 PM
Originally posted by MCronin
In Maya or Max's renderer, you give it a NURBS sphere, the software then tesselates the sphere to triangles and then clips it and renders it. With PRMan, it takes the NURBS sphere directly as a parametric surface, clips it, and then in the process of rendering generates X polygons per pixel based on the defined shading rate on a per object basis.

I might be wrong, but I am pretty sure that prman creates the micropolygons on an area basis (basically a breakdown of the screen into squares) rather than a pixel basis...any displacement having to be 'contained' in one of those areas: if you displace a point from area 1 to area 2, and the surface spikes off the edge of area 1, then when rendering area 2 the renderer won't know anything about the surface points of area 1 and the spike won't be continued. Makes sense ? What I am trying to say is: if you have complex displacements, you will have to define a render area that covers the whole screen which means creating the whole thing in memory which is pretty much the same as creating the whole scene before sending it to the renderer, at least from a memory perspecitve. Or did I miss something (I haven't used prman in years, back then computers only had a few megs of ram...) ?

If iso surfaces can be implemented as real parametric surfaces without any polygon conversion, then great. But aren't NURBS resolution independent in theory, too, and it is just their implementations that are limited ?

Anyway, time to get that 2nd gig of ram...:D

Morganism
12-13-2003, 11:20 PM
Well, I don't know anything about this, but is sounds like Iso surfaces are more than just resultion independent. Since they aren't defined by points, they would also be topology independent, so to speak. You could morph between any number of objects without having the same topology, or you could animate the thing like it was a liquid, folding over or into itself without any intersecting or topology limitations.
Or am I missing something?

kemijo
12-14-2003, 02:02 AM
Originally posted by Morganism
Well, I don't know anything about this, but is sounds like Iso surfaces are more than just resultion independent. Since they aren't defined by points, they would also be topology independent, so to speak. You could morph between any number of objects without having the same topology, or you could animate the thing like it was a liquid, folding over or into itself without any intersecting or topology limitations.
Or am I missing something?

Yes, that's correct...it also means that with current technology they are almost impossible to attach texturing coordinates to, as the topology is ever-changing if animated. So a texture map or procedural pattern that was locked to the surface woud currently be impossible...which might have something to do with why their use is limited. Any patterns would swim through the object like a 3D texture on deforming geometry, making them useless for many typical applications. In Houdini they are typically used to look at the shape of a volume, like Houdini's I3D image format, which is basically a 3D texture that you can create and write to disk. The Iso SOP will let you visualize the shape of the 3D texture, and you render it with a fog shader. The iso surface is usually not rendered. In Maya Fluid Effects, the fluid has two display modes - volume/voxel (volume pixel) display, or 'surface' display, which is an iso surface.

If iso surfaces can be implemented as real parametric surfaces without any polygon conversion, then great. But aren't NURBS resolution independent in theory, too, and it is just their implementations that are limited ?

Yes, this was mentioned earlier in the thread. A NURBS surface (and subdivs) rendered with Maya's renderer need to be tesselated into triangles (completely different from micropolygons - which I don't believe Maya renderer supports). But in RenderMan (and Mantra), this step is not necessary...like Mcronin said, no matter how close you get, you would always get a smooth curved edge. I think triangle tesselation is necessary in Mental Ray though...anyone know for sure?

playmesumch00ns
12-15-2003, 09:31 AM
Originally posted by Marc Andreoli
I might be wrong, but I am pretty sure that prman creates the micropolygons on an area basis (basically a breakdown of the screen into squares) rather than a pixel basis...any displacement having to be 'contained' in one of those areas: if you displace a point from area 1 to area 2, and the surface spikes off the edge of area 1, then when rendering area 2 the renderer won't know anything about the surface points of area 1 and the spike won't be continued. Makes sense ? What I am trying to say is: if you have complex displacements, you will have to define a render area that covers the whole screen which means creating the whole thing in memory which is pretty much the same as creating the whole scene before sending it to the renderer, at least from a memory perspecitve. Or did I miss something (I haven't used prman in years, back then computers only had a few megs of ram...) ?


What you are referring to are "buckets". To avoid having to keep the whole scene database in memory at one time, the modified Reyes algorithm chunks space into buckets (by default 16x16 pixels I think). Objects are only kept in memory for the buckets they affect and are discarded as soon as possible.

They way the renderer judges this is on the bounding box specified for the object. The renderer doesn't know where a displaced point will end up until it's shaded, but it might have already decided not to assign a particular chunk of your object to a bucket that you want some points to end up in once they're displaced during your shader execution. This results in the ends of your displacement being "chopped off" by the edge of the bucket.

The way PRMan gets round this is by allowing you to specify a displacement bound, essentially an extension to the object's bounding box to allow for the extra space you require for displacing the object.

Obviously this means that the object will be in more buckets, so will take up more memory and be slower to render. This is, however a small price to pay for the efficiency of the Reyes algorithm. Basically it means if you want to displace a teeny-weeny sphere with huge spikes that take up the whole of the screen, it would be far better to model that than achieve it by displacement. But then that's common sense anyway.

Back on the iso-surfaces, it seems like fluids and stuff might be a good use for the technology, but then how often do we use that?

Then again, it's only a tech demo, it's nto like cebas are going to be selling fR off this tech (at least I hope not for their sake)

Valkyrien
12-16-2003, 01:36 AM
that's just...wow! nuff said;)

thev
12-14-2004, 01:15 PM
It might be interesting to know that in the end, CA Scanline used VRay for their fluids project:

http://www.chaosgroup.com/news/20040604-01.html

richcz3
12-14-2004, 05:09 PM
I have never heard of ISO surfaces, but if it is the result of a mathamatical equation then the end result (quality of the visual) would appear to be dependent on.
1. The amount of time allowed to calculate.
2. The speed of the hardware crunching the numbers .
Without a mesh it looks resoltion independent, but that actually soounds like it adds more to the calculations overhead becasue of its dynamic properties. It would be interesting to see if there could be a hybrid of Nurbs and ISO surfaces.

Thalaxis
12-14-2004, 05:18 PM
Think of procedural shaders.

An isosurface is basically a surface defined by an equation that yields a constant; for example:
x*x + y*y + z*z = r*r
(a sphere in 3 dimensions).

Of course, it could range from something so simple as a plane where x = some_constant to a 12
dimensional Calabi-Yau space that shows the shape of space-time on superstring scales, so your
computational mileage will vary :D

CGTalk Moderation
01-16-2006, 11:00 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.