Sorry if this is getting repetetive. In an earlier posting there was some speculation regarding what we would expect of the P5 rendering engine. I was referred back to an even earlier posting where 'The Man in the Know' Kupa described it as a 'renderman compatible raytracer'.

This baffled me, since the Renderman standard is for the most part an import/export or interfacing format.

That is to say, it is generally used either to export scenes from a modelling/animation application into a seperate rendering application (or deliver them to a render farm), or alternately to allow programmers to actually write programs that interface directly with the renderer (Python?), without an involving an modelling/animation application.

'Renderman compatibility' is something that is generally applied to stand alone renderers (and is granted by licence application by Pixar). In order to achieve it, the renderer needs to handle a number of basic modelling features, such as NURBs, Spline and Bezier curves and, possibly, some level of procedural texturing.

Why would the Poser5 internal renderer need to be compatible with an external standard? Does this mean that the P5 renderer is going to be a stand alone application and you will have to export the scenes from the main app and import them to the renderer, or does it mean that you will be able to import additional scene elements to P5 for rendering.

Frankly either case seems odd (or impractical). Perhaps there was just some unintentional confusion, or blurring between the export features (Renderman) and the internal renderer, or perhaps the Renderman RIB format is going to replace .pz3 as the standard P5 save file format :-o (I don't know whether this can be done - I doubt it).

Acknowledged, the original posting may well have been highly speculative at that early stage in development. However, if anyone can shed any light on this announcement, I would be very interested to hear.

jw

Maybe CL wants to focus their efforts on posing issures and they purchase the new render engine from a third party?

Steve Cooper told me that it will be their own engine. They are writing it themselves. They are not purchasing one.

I think it would be nice if they could release more details and at least tell us what quarter they're shooting for. I am tired of having to use the plugin to render in another app.

P5 will generate RIB internally from a scene and pass it to a built-in BMRT type renderer?

If that is the case I don't see how they could manage to gain a 'Renderman Compatibility' licence from Pixar. I would expect extrenal interfaces would be part of the basic requirement (Python again?). Also why would they want to constrain the internal pipeline to an external scene description format?

Poser already exports RIB files.

(OK. Don't slap him...) Mark, it only exports one frame at a time. The standard is to export all frames, so that the renderer can render the animation. Ever try to export 900 frames, one... at... a... time... ?

Just to clarify, Poser only exports a small subset of the Renderman standard, specifically, only polygon information for describing Poser's mesh models. In order for a renderer to describe itself as Renderman compliant, it has to be able to import the full set of Renderman API calls, and implement a basic subset, including splines, Bezier patches and NURBs.

P5 may implement a few of these features, but even then, in order for the rendering engine to gain Renderman compliance from Pixar, it would still have to be able to import and render all of the required features, regardles of whether they are available or usable in the main app.

Renderman is not an application or a rendering method, its an interface standard (API and file) that allows seperate applications to share scene descriptions - Renderman compliance is import standard. Implementing it and gaining a compliance licence would seem to be extremely inefficient where most P5 users would either be rendering from within the application or exporting to third party applications or high end renderers.

What may make some sense is for Poser to be able to make RI calls and do a fully-compliant RIB export on its own, for no other reason than to ensure that Poser output can interface directly into the higher end renderers. It may be a good enough reason for some... "important" situations. For example, if the animator renders to 640x480 to ensure that the scene has all the needed elements (maybe sans background scenery and special effects), the director can have the animation rendered to HDTV DVD quality offline, add in the background and special effects from other programs, and the director can have some level of assurance that the animation will, in fact, render. The data given on the Final Fantasy DVD said they used at least three renders per scene - animation, background, and special effects. So, making Poser Renderman-compliant may make it acceptable for the director to just release the Poser output to, say, Exluna's Entropy rendering, before it goes to editing.

Yes RIB exports will probably be essential for all the elements that P5 can model and animate, but that's actually fairly easy to achieve. It doesn't need to include anything P5 itself doesn't represent and extracting the data from the internal structures and formatting it in the RIB ASCII description is pretty straightforward in programming terms.

However the 'compliance' issue and the original posting describing the rendering engine as Renderman compliant is a reference to import capabilities of the renderer itself, whereas ensuring that the RIB export matches the P5 scene is an export (and hence not a compliance) issue.

As I said at the start, I am dubious about whether the 'Renderman compliant raytracing engine' statement was accurate since it would require putting a lot of work into a feature that few people, if any, would find a practical use for, despite what they might think.

Note that, so far as I am aware, the only Renderman compliant applications on the market at this moment are standalone renderers.

Interfacing with a third party engine as suggested by MadYuri would explain this.

It could be possible to import additional scene elements from other apps, but the suggestion would seem to be that these elements would go straight to the renderer, and couldn't therefore be manipulated/animated in the main app. Additionally, the Python interface could be expanded to allow Renderman API calls and add elements during the rendering process, now that would be useful for me, but I don't know about the majority of users.

Whatever. They need to improve the rendering engine and forget about the renderman compliance. My point was most people don't care about this.

It is probably too late to forget about it, Mark. That is the kind of decision which comes very early on in the development cycle. And, you can rest assured the render engine will be much improved. We just hope it's not just a raytracer. We hope it is a scanline engine with optional raytracing, just in case we want to wait four days for a render.

I understand that (I do write software for a living). Do you work there? How do you know it will be much improved? Are you just going by what they've promised or do you have some actuall insider info?

Lots of software and other engineers in here. Me, too. Steve Cooper at Curious Labs said so in a thread a while back. I think he is the Product Manager. That's where the 'renderman-compliant ratytracer' quote came from. He also said there would be hair and clothes physics (yum...:). Didn't mention collision detection, though. Search for 'Kupa' in the Poser forum. You should find his posting.

Freudian slip ...raytracer...

"We hope it is a scanline engine with optional raytracing,
just in case we want to wait four days for a render."

it will be interesting to see what they come up with
But raytracing does not automatically Doom one to three and four day renders
even for animations.( unless you use bryce:-( )
I render in Cinema and it has a very fast raytracer that I use for my Propack animation
imports on a very OLD Mac 300mhz G3.

I would HOPE that they Dont get rid of the Scanline because I use poser for
low res previsualization animation renders before opening up the scenes in cinema
for proper lighting ,volumetric atmospheres and rendering.
But lets be honest, MARK is right!!
The great majority of poser users only concern about P5 is backwards compatibility
with their existing investment in figures and excessories

NOT " renderman compliance"
and us small minority of animators will likely still be better off
inserting animated poser characters into the true 3d environments of Lightwave, Cinema, MAX etc.

Yes, Mark is right.

However, this thread is about the fact that a reputable statement was made by Steve Cooper of Curious Labs that Poser 5 will have a renderman-compliant engine. I've made the statement that that can't be changed, whether we like it or not.

And since it has been stated by two people here that people do good work by hosting Poser scenes in other environments, why did CL make the decision to go with RI?

Are we all missing something important? (I think the assumption is that CL is not just, like, way stupid.)

And, given the fact that Kupa also said 'raytracing,' does that necessarily mean the demise of their scanline engine? So far, and especially based on Pixar's PRMan, I'd say the data leans toward a scanline engine with optional raytracing. But we have no definitive data from CL on this.

BTW - The more I look at Cinema 4D, the more I like.

And Wolf, good luck on your movie!

Mark is right, the majority of Poser users don't care about this, or at least about the underlying technology, but obviously I am curious, which is why I posted the original question :)

Incidently, the reference to a 'Renderman compliant raytracer' still doesn't make sense to me. Again this is an import compliance standard that Kupa referred to, not an export standard.

As an aside, my main concern in the previous thread was that CL have probably based the decision to implement a raytracer at least partly on feedback from their customer base, and, for most of those concerned, the term 'raytracing' is probably synonymous with 'high (or better) quality rendering' which is what they really wanted.

So CL may well face some level of dissatisfaction if raytracing performance has a significant impact on rendering times, as I suspect it will for the first generation of a new product.

Personally, I think that for the majority of users, CL would have spent their development budget on improving the scanline rendering technology, and there is plenty of scope for improvement in that technology. Kupa stated that the scanline renderer would be retained, but gave no indication whether there would be any improvements.

Acknowledged, I am making assumptions here on what people really want, but it has been fairly obvious from many of the forum postings that there are a lot of people who don't understand (and for that matter don't care) about the technologies or terminologies so long as they get the results they want.

Beware of what you wish for...