green: WRT Aqsis, it's about comparable to BMRT in image quality, but considerably slower. Considering Larry Gritz (author of BMRT) originally worked a Pixar, this isn't too surprising.
Aqsis actually does some things better, eg motion blur. I'd recommend downloading it and having a quick play with their provided examples - shouldn't take long.
Incidentally, why so down on BMRT?
þæ
Renderman Support Started
Moderators: jesterKing, stiv
Yes, you are right - kind of. It makes sense to have that structured view on your shader tree.green wrote:I have not tried aqsis yet. But I havent seen any good image generated from it yet.
http://www.dream.com.ua/thetool.html
Here is what you want. I suppose.
Writing a new editor like this one(but much better) is probibly not something that will be done (by me anyways) within the next 6 months. So there is no point in waiting for it I think.
I am going to try and create shaders on the fly from the material editor in blender for the exporter though.
The time? Yes, thats an important factor on this task. So, let's not wait for it.
Doing that script for exporting the materials out of blender into renderman format is a good thing, good to learn about the transformation but the goal is to mix both worlds. The best would be, if blender internally handled renderman shaders and used them as good as it can. The advanced features could then be done in the renderman renderers.
But this interface has to be done as easy as every control in blender!
/Kniffo
About the shaders:
Whats planned first is to have very very basic shader conversion support like so:
1. Read the material editor for rgb and shiny etc values.
2. using ´these values write a shader file on the hd
3. compile this shader file
4. use the compiled shader in the exported scene for that object
This will then increse in complexity with every release and more and more material and texture options will be supported
About using external shaders:
At first I am just going to implement an option for the user to write in themselfs what values and shaders the object should have in a text input widget.
But having a gui for it will probibly come sooner or later. sgefant wrote something like this for blenderman(it was never released though). its possible to do but I dont know when it will be implemented.
Right now im just trying to get all object types to be exportable and get animation support working. Then I will start on the shaders/matetrials stuff
Whats planned first is to have very very basic shader conversion support like so:
1. Read the material editor for rgb and shiny etc values.
2. using ´these values write a shader file on the hd
3. compile this shader file
4. use the compiled shader in the exported scene for that object
This will then increse in complexity with every release and more and more material and texture options will be supported
About using external shaders:
At first I am just going to implement an option for the user to write in themselfs what values and shaders the object should have in a text input widget.
But having a gui for it will probibly come sooner or later. sgefant wrote something like this for blenderman(it was never released though). its possible to do but I dont know when it will be implemented.
Right now im just trying to get all object types to be exportable and get animation support working. Then I will start on the shaders/matetrials stuff
Well there no problem in installing that thing .. hmm.green wrote:website: nope, no hype wanted
bmrt bad becouse:
1. Its dead
2. Its slow
3. its impossible for windows users too install (you wouldnt believe how much mail I got from windows users that 1. didnt know how to read readme files and 2. people that failed to install it)
4. its dead
green - it's dead but it's a renderman renderer. Which one would you prefer, if not BMRT - to use renderman output made by blender????
It's wise to make a renderman output, but for what? I don't think, that anyone has PRMan at home...
kniffo wrote:Well there no problem in installing that thing .. hmm.green wrote:website: nope, no hype wanted
bmrt bad becouse:
1. Its dead
2. Its slow
3. its impossible for windows users too install (you wouldnt believe how much mail I got from windows users that 1. didnt know how to read readme files and 2. people that failed to install it)
4. its dead
green - it's dead but it's a renderman renderer. Which one would you prefer, if not BMRT - to use renderman output made by blender????
It's wise to make a renderman output, but for what? I don't think, that anyone has PRMan at home...
well. the original message had this in it :
"""""""""""""""""
It will by default go to 3delight. But this will be changeble to other renderman renderers through some form of configuration.
""""""""""""""""""
(the configuration part is done now)
3delight is a nice renderer
An Idea on using shaders
An idea I had the other night on making shaders (Actually, how to handle ANY object not native to Blender).
If we dynamically linked to a lib that exported a new object type (eg shader), the object could carry all the data specific to the new shader.
You could then apply a Blender material to this object. The shader would get the common attributes from the blender material, and use the blender material in the internal renderer.
The shader object would then be exposed to renderman (or whatever) as a shader and objects that used the Blender material would be exposed as using the linked shader.
A user interface that makes this relatively transparent to the user needs to be thought of. Perhaps someting similar to a tabbed page (Page 1, Page 2 buttons anyway), where Page 2 is generated by the external lib and Page 1 is the existing Material Edit Screen.
In the 3D view and in an internal render, the shader objects would just be ignored.
Using a new renderer would be simply selecting a different dynamic lib.
This allows a great deal of flexibility with a minimum impact on the existing code.
Bob W
AKA Detective Thorn.
If we dynamically linked to a lib that exported a new object type (eg shader), the object could carry all the data specific to the new shader.
You could then apply a Blender material to this object. The shader would get the common attributes from the blender material, and use the blender material in the internal renderer.
The shader object would then be exposed to renderman (or whatever) as a shader and objects that used the Blender material would be exposed as using the linked shader.
A user interface that makes this relatively transparent to the user needs to be thought of. Perhaps someting similar to a tabbed page (Page 1, Page 2 buttons anyway), where Page 2 is generated by the external lib and Page 1 is the existing Material Edit Screen.
In the 3D view and in an internal render, the shader objects would just be ignored.
Using a new renderer would be simply selecting a different dynamic lib.
This allows a great deal of flexibility with a minimum impact on the existing code.
Bob W
AKA Detective Thorn.
Re: An Idea on using shaders
Well, one of the concepts of the renderman interface is defined as following:rwenzlaff wrote:An idea I had the other night on making shaders (Actually, how to handle ANY object not native to Blender).
If we dynamically linked to a lib that exported a new object type (eg shader), the object could carry all the data specific to the new shader.
You could then apply a Blender material to this object. The shader would get the common attributes from the blender material, and use the blender material in the internal renderer.
The shader object would then be exposed to renderman (or whatever) as a shader and objects that used the Blender material would be exposed as using the linked shader.
A user interface that makes this relatively transparent to the user needs to be thought of. Perhaps someting similar to a tabbed page (Page 1, Page 2 buttons anyway), where Page 2 is generated by the external lib and Page 1 is the existing Material Edit Screen.
In the 3D view and in an internal render, the shader objects would just be ignored.
Using a new renderer would be simply selecting a different dynamic lib.
This allows a great deal of flexibility with a minimum impact on the existing code.
Bob W
AKA Detective Thorn.
"Users of RenderMan oftne find themselves intially sepereated into two camps: users of sophisticated modeling programs that communicate the scene description directly to the renderer and who therefore never see the data, and users who write scene description themselves ( either manually or, hopefully, by writing personal special-purpose modeling programs ) and who need to be fluent in the capabilities if RI API. Over time, however, these groups tend to blend, as modeler users learn to "supplement" the scene description behind the back of the modeler and thus become RI programmers themselve." [Advanced Renderman]
This describes the situation we have. Wo do not only have modeler users, which want to have a nice ui and do not want to deal with the internal shader/renderer functionality, we also have users that want to change shaders and scenes after creation by a modeler. So I think, it's a bad idea to handle the renderer and shaders only internally. I think, it's better to have an output as a file ( shaders as well as scenes ) in a renderman format and than have a ui where you can start the externel renderer by calling the executable.
It's as fast as your internal version and it's open to everyone who's interested in tweaking the scenes and shaders.
Look, how Ayam it's doing...
/Kniffo
The problem this leads to is now you have two sets of shader data that you have to keep in sync. You tweak the external shader file, and the changes you make there do not "back annotate" to the internal renderer for previewing.This describes the situation we have. Wo do not only have modeler users, which want to have a nice ui and do not want to deal with the internal shader/renderer functionality, we also have users that want to change shaders and scenes after creation by a modeler. So I think, it's a bad idea to handle the renderer and shaders only internally. I think, it's better to have an output as a file ( shaders as well as scenes ) in a renderman format and than have a ui where you can start the externel renderer by calling the executable.
It's as fast as your internal version and it's open to everyone who's interested in tweaking the scenes and shaders.
Besides, make one of the possible attributes a link to a file, and we have both worlds. The things that can't be edited well in Blender can be altered in the file, but the things that can be altered inside Blender effect both the Blender material and the shader.
My method also has possible extentions to other data (such as surface types). The "external object" could be represented as an aproximate blender object, but replaced with its proper form when delivered to the external renderer.
Bob
Green, i recently stumbled upon this web site : http://www.lysator.liu.se/~ture/terry.html
It seems that some one is trying to create bindings for the renderman interface in python. It may be of help as you have already got knowledge of python with blender. Just thought i would mention it.
It seems that some one is trying to create bindings for the renderman interface in python. It may be of help as you have already got knowledge of python with blender. Just thought i would mention it.
oh, i almost forgot, i have found bmrt for download on the rhino (nurbs modeling) website - http://www.rhino3d.com/bmrt.htm
the nice thing is, it IS being developed further apparently (on the download page it says users will be emailed when new versions become available), if this is true, then we have a nice renderman renderer available for free (non-commercial) use. as to the speed comparisons between it and 3delight, the speeds at which it renders is all dependent on the hardware and software configuration you use. some computers may be faster with 3delight, others may be faster with bmrt.
the nice thing is, it IS being developed further apparently (on the download page it says users will be emailed when new versions become available), if this is true, then we have a nice renderman renderer available for free (non-commercial) use. as to the speed comparisons between it and 3delight, the speeds at which it renders is all dependent on the hardware and software configuration you use. some computers may be faster with 3delight, others may be faster with bmrt.
it may look good, but most renders take hours to complete.impdotorg wrote:POV-Ray as a renderer for Blender is an excellent option. Not the only one, but a viable one. You have access to the source code and are not dependent on a commercial entity. As far as the quality of it's output, that is dependent on the quality of the input.povray is crap
it's slower than gramma cought in mollasses!!!
dittohead