a couple of months ago i got an advice from an professional artist to use creases in my SDSs instead
of this tiny little borderpolygons on the edges as i used to do.
Yesterday i made a test and changed a complete mesh und made use of creases.
But with every crease added pixie rendered slower and slower.
I didn't bother about that, cause i thought WindowsXP has its five minutes, but when i nearly finished
the remeshing-action pixie tried to consume extreme much memory so that it starved running out of memory.
The model without creases renders perfectly smooth, but with creases i got no luck.
Have i overseen some options or attributes?
What do you recommend to solve this problem?
What is the best geometrytype for pixie?
-sds without creases (like my old model)
-sds with creases (a lot more storagememory friendly)
-completely pretesselated Meshes (would be a nightmare for the memory and quality)
You can find the problematic scene (exported from silo) in this package:
together with the old original sds-mesh and the simplyfied mesh without creases.
I hope this problem can be fixed :-(
nevertheless have a nice day
an unlucky Mario F.
I downloaded you're files and saw the same thing. I took out the "creases" from the creases.rib file and it was fast again, but I did notice that there seems to be wrinkles around the holes which got me thinking that maybe the mesh is not optimized for a SubD surface or maybe you need to build you're model in quads (if you haven't already). I found out a few years back that if you don't use quads in Mental Ray's Subd's the render times, and memory consumption, will skyrocket. I'm not sure if Pixie is the same way, but it might be worth a try.
The mesh is fine. With "not optimized", you probably refer to "being manifold". Renderers should be able to deal with non-manifold meshes in any case and merely bitch and try to render them as good as possible. It is a myth that your mesh needs to have all quads for Catmull-Clark subdivision scheme. On the contrary, that scheme ensures a mesh becomes all quads after the 1st subdivision step, so not measure by the artist are needed to ensure this.
I tried to render Mario's RIB with PRMan & 3Delight. Both renderers don't have a problem with the mesh. 3Delight takes 2.1 seconds to render the RIB (with creases) and uses a negligible amount of memory. The RIB w/o creases and bevels instead takes 2.3secs on my box with 3Delight, memory consumption is slightly higher than for the crease one but still not noteworthy. So it's definitely a Pixie issue that should be addressed at some time.
I might add that I second using creases. On hard surface modeling -- which seems what Mario's into -- this saves a shitload of geometry in your RIB/your 3D scene files.
Moritz is quite right about all the faces becoming quads after one level of subdivision.
One point that is worth noting (though not necessarily altering your modelling style for) is that vertices which have a number of edges N ending at them, where N!=4 will result in a different method evaluation of the surface. This is true for PRMan, and I belive 3Delight, as well as Pixie. Generally these parts of the surface are slower to rasterize than the grid of quads, which is far easier to evaluate exactly.
So you don't have to avoid vertices with non valency 4 at all costs, but certainly rendering a triangle mesh as a catmull clark subdiv might not produce a particularly nice or fast render.
Generally the formulation of creases works by subdividing a number of times with the sharp subdivision rules, and a number of times with the smooth rules to produce a crease of the appropriate sharpness.
In your example, the creases were 10 (infinitely sharp for Pixie and PRMan). To achieve the smoother edge a lower number can be used.
Pixie normally handles creases and corners pretty well, and I have some pretty complex examples which render much much quicker than the rib you sent. So there's definitely something odd going on there. I just need to dig about and understand what it is.
It is a myth. Mental delay needs the mental matter library to render subdivs natively. Otherwise, it is up to the host app to send a pre-tesselated version of the mesh. As was the case until very recently in most apps like XSI & Maya that integrate this "renderer".
I have been using Catmull-Clark subdivs since they became available in PRMan in 1997/1998. There was /never/ a problem with non-quad meshes. Neither was there ever in 3Delight. If you implement the original version of the algorithm there is only a problem for extraordinary vertices at boundaries, but not inside the mesh. If your mesh forms a watertight closed manifold (as seems to be the case for Mario's models), there wouldn't be a problem even with a reference implementation of the original algorithm. That's why I call it a myth. If there is a problem in certain other "renderers" we're talking not Catmull-Clark anymore but a modified, different or incompletely implemented subdivision scheme.
Regarding the crease algorithm: Pixar has a patent on the algorithm George describes. Hence 3Delight uses a different one that gives slightly different results (particularly near vertices were two creased edges meet).
I never heard about the maximum sharpness being 10 in PRMan. The default max. in MtoR is already 20 on the slider for setting crease values. I think if you zoom in enough, even at 20, the creases will start to look round once one's close enough. I firmly believe that only RI_INFINITY triggers real sharp creases in PRMan, but I could be wrong.
Lastly, 3Delight does not convert rectangular sub-meshes into b-spline patches anymore -- to my best knowledge (they used to in the past, like PRMan). Their subdivision algorithm is so fast & well optimized for all cases by now that plain subdividing until shading rate is met is faster under all circumstances for them.
Hence my understanding (and experience) is that vertices with valence != 4 don't make much of a difference in this renderer at all.
PRMan also implements a different optional scheme (activated by a special tag) for triangles that blends into the Catmull-Clark one.
> It is a myth. Mental delay needs the mental matter library to render subdivs
> natively. Otherwise, it is up to the host app to send a pre-tesselated version
> of the mesh. As was the case until very recently in most apps like XSI & Maya > that integrate this "renderer".
Ok. Fair enough, but as a net result there is an issue with no quad surfaces. Though this is not an issue with the Catmull Clark ruleset, it is an issue with the pipeline used in some cases for MR.
> I have been using Catmull-Clark subdivs since they became available in PRMan
> in 1997/1998. There was /never/ a problem with non-quad meshes. Neither was
> there ever in 3Delight. If you implement the original version of the algorithm
> there is only a problem for extraordinary vertices at boundaries, but not
> inside the mesh. If your mesh forms a watertight closed manifold (as seems to > be the case for Mario's models), there wouldn't be a problem even with a
> reference implementation of the original algorithm. That's why I call it a
Agreed. As I previously stated, there is no reason for non-quads to be an issue with a properly implemented CC scheme. Which is what Pixie has. That is not the issue here.
To clairify one more. Pixie should not have issues with non-quads in subdiv meshes.
> Regarding the crease algorithm: Pixar has a patent on the algorithm George
> describes. Hence 3Delight uses a different one that gives slightly different
> results (particularly near vertices were two creased edges meet).
We also have slightly different rules at corners and creases! Since 3Delight's source is not open, I have no idea what they do under the hood.
> I never heard about the maximum sharpness being 10 in PRMan. The default max.
> in MtoR is already 20 on the slider for setting crease values. I think if you
> zoom in enough, even at 20, the creases will start to look round once one's
> close enough. I firmly believe that only RI_INFINITY triggers real sharp
> creases in PRMan, but I could be wrong.
RiSpec says infinite sharpness is infinity. That's not the case. Implementation is via a finite set of rules. This does not mean that only integer values are handled. But it does mean that if all sharp style rules are used (ie copy) then the edge will be inifitely sharp. If it's 20 in PRMan then I stand corrected, but it is a finite quantity due to the way the rules work. My beleif is that zooming in on such a corner will show a perfectly sharp edge.
> Lastly, 3Delight does not convert rectangular sub-meshes into b-spline patches
> anymore -- to my best knowledge (they used to in the past, like PRMan). Their
> subdivision algorithm is so fast & well optimized for all cases by now that
> plain subdividing until shading rate is met is faster under all circumstances
> for them.
OK. To be fair I have no idea what it does under the hood. However, I see no good reason to not do this. Memory requirements (and processing time) for recursive subdivision is a growing progression which gets rather large. To me it seems stupid to do 10-30 subdivisions to match a screen space metric.
Fundamentally a 3x3 set of subd quads in some circumstances can be represented exactly by a bspline patch. The quads are fundamentally flat, so you'd have to subdivide a hell of a way to match the curvature, whereas the bspline patch will match exactly.
Worse still, raytracing a surface may require arbitrarily fine tesselations....
At any rate, I really wished to throw light on what Pixie is doing here.
> Hence my understanding (and experience) is that vertices with valence != 4
> don't make much of a difference in this renderer at all.
The algorithm to render / exactly evaluate such a surface is inherrently more complex than that for other parts of the surface. I do have scenes which present a slowdown from this in PRMan, though it is not large.
For Pixie, they will be slightly (but not much) slower.
> PRMan also implements a different optional scheme (activated by a special tag)
> for triangles that blends into the Catmull-Clark one.
There are a number of alterations that could be employed or entirely different rulesets / schemes. We do not implement anything in this space yet. Though we might in the future.
It is not a myth, it's a fact; I fought with the problem a million times. Maybe Mental Ray fixed the problem in later versions, though I wouldn't know because I'm still on an earlier version. But you COULD NOT render a SubD that wasn't a quad; this was a well known bug. They probably fixed it later, but I wouldn't know. Also, when using the Maya renderer, the SubD's would slow down big time when the model wasn't quads. These are not renderman renderers, but it shows that other renderers have had problems with SubDs, or had them at least.
By "not optimized" I mean that you have too many polygons in you're model.
It is true that some (and possibly even current versions of MR) have issues with non-quad subdivs. It's something I've run into in the past.
Conventional wisdom seems to be that for most meshes there will either be non-quad faces or non valency 4 vertices....
Pixie should handle either.
Either way, the math of subdivision surfaces dictates that cartain configurations of surfaces are harder to render than others. Pixie does not use a naieve recursive subdivision algorithm, but seeks to represent parts of the surface in ways that can be _exactly_ rendered without further subdivision.
Creases neccessetate at least some subdivisions with one ruleset, and possibly further ones with a smooth ruleset. But the exact number of subdivisions needed is where the issue lies. I think we can get away with less (and therefore far less time and far less memory) than we currently use. But there is some invesigation to do here.
I have a tweak which makes the render considerably faster, but I'm just in the process of understanding the corner cases and safety of such a change.
wow what a discussion!
After the first post i started to remesh the model and on that occasion i disassembled the model in seven parts.
I made tests with Pixie and 3Delight.
Pixie rendered the composition of the parts without problems.
But just now 3Delight run into problems with this composition.
This could be my mistake, because i didn't use the tag "hole" for the (then to be filled) interfaces between the parts.
Although this works with Pixie in a reasonable time my expected "Look" gets lost at the interfaces between the parts.
So i recombined the parts.
This solves the problem that 3Delight has with the component parts.
Pixie on the other hand consumes again huge amounts of memory which slows down the rendering extremely.
But in contrast to the other mesh from friday/saturday i get a complete render without running out of memory
(although Windows gets into trouble again).
You can find the ribs as well as the silo-files in this package:
Well, the disassembling of the model makes it better run with Pixie but on the interfaces between the parts i loose
the "Look" i want. Rendering with 3Delight in this composition brings me problems because of the holes,
i should declare, which seems not to be that easy with the modeling programs i use.
So i'm now in the situation that i have to manipulate the meshes just for every single renderer.
This is simply not possible on my side.
To get one part rendered pleasantly in at least two renderers i spend three complete days.
I'm afraid i don't get old enough to bring compositions like this:
in a better shape.
Unthinkable the whole vehicles.....
Like Moritz stated i want the "Look" of rounded edges.
All models on my homepage are modeled in the good old Cinema 4D 7.
The first models where done as pure polygon objects which looks everything than realistic.
In the newer models i changed this to subdivision surfaces, which unfortunately have no crease-support in C4D 7.
So i simulated the creases with pretty overloaded edges, which makes the modeling as well as the rendering a pain.
Since Moritz' suggestion to use creases i saw a chance to slim the files and speed up the modeling/rendering.
I hope to continue my works with creased sds, nurbs and patches.
Because i don't want to use C4D any more (personal decision) the only alternatives for now are Blender, Silo and self made tools for RIB-processing.
After this surprise with only one mesh i have no clue, how i could go further with my models.
So what would you suggest as a solution?
-The original mesh with overloaded edges seems to be the savest model, because this can be rendered with nearly all RIB-renderers
(except Aqsis, but this continues suffering with every sds from me).
But this has high storage memory costs and with larger compositions i run into rendering memory problems.
The modeling of such meshes is a pain as well.
-The first mesh with creases is a "quick" simplification of the overloaded one, but this is the origin of this thread.
-The second decomposed mesh, which semms to be only provisional, because i get quality loss at the interfaces.
-The third mesh which runs even on my recent computer with Pixie (with a coughing Windows because of heavy memory consumption)
and with exorbitant time costs for modeling. (Air refuses to render the rib, because of wrong parameters, so there might be mistakes in it)
I have to admit, that i don't understand the argument about mixing up triangles and quads.
I agree with Moritz and George, that after the first step of the sds algorithm every non-quad should be subdivided into a couple of quads.
So when this would be the problem i assume that the renderer makes a mistake at this stage.
But till now i've only read about this algorithm, not implemented it.
I did the second remeshing to avoid interfering this problem with the creases with the result of a marginal improvement.
One last thing:
i want to use every RIB-Renderer that is available for me.
The possibility to switch the engine depending on the situation is the biggest reason for me to use ribs.
It's not my intention to blame someone or some projects.
If i could help to solve such problems i'd be happy.
Now i need a rest, this weekend was a desaster.
have a nice day
Can it be, that 3Delight renders sds not 100% correct?
Maybe i forgot an Option/Attribute but i see some distracted edges in the pictures with the creased edges.
Thank you for the feedback on the subdivision surfaces. We are doing our best to make Pixie as easy to use as possible. That's why we can use your constructive feedback like this.
I think there is an easy solution to this problem. So stay tuned for Pixie 2.0.
Meanwhile, to recap; Pixie should work with quad/non quad subdivision meshes with tags and crease vertices/edges. If you have a mesh that fails to render correctly, send it over and we'll take a look. Keep in mind, however, that the outputs from Pixie/PrMan/3Delight may be slightly different due to the different subdivision rules. I'm doing my best to keep Pixie's subdivision consistent with PrMan's.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.