Well, I could be wrong, but personally I think it really is more because of the ‘programming’ part. Somehow people often seem to think that they have to program shaders themselves whenever renderman shaders are mentioned.
And programming is really very scary to most artists you know I feel the same way whenever I think of modeling…
If the shaders are used and refined enough, they could easily be optimized and put directly into the renderer.
I would think a good optimizing compiler and VM would be ideal, the shader could be edited ‘live’ right inside blender for anyone who would want to. Compiled code would then take very little space as well, and be portable across different systems.
Actual compiled C-code is probably only needed in very few cases.
RSL has a few flaws that such a system could overcome like not being able to execute a piece of shader code only once per frame.
Being able to easily make changes to the language is part of the reason I did the compiler in python btw. At first I want it to be RSL compatible, but then I would make my own adaptations (but still keep it compatible of course). For instance, making things like the uniform/varying thing easier, let the compiler figure it out, instead of leaving it to the programmer. Same thing for transform(), etc.
Also translation to other shading languages would be nice, like GLSL and stuff like that. But all that probably is still very far away yet…
Anyway, I updated the quietdune page on my site a bit with some images of the example files included.
Most probably are quite familiar to users of the old bmrt renderer.
i can see how the shader could be done either with nodes, or you could like link a file trough a special ‘insert’ node. this way there would be a way for each, aka. to each their own.
The sourcecode of quietdune is now in main the Blender svn branch, and the Peach team (read Brecht is now working on the code.
Now it’s confirmed that Brecht is working on the code for the micropolygons and other QDune stuff, with Bretcht behind it, it’ll probably get done and in this case it may be used in the Peach movie.
No, there is no build. The sourcecode currently in Blender (blender/extern/qdune directory) is a standalone program, if you want to build it then you will have to make changes to the SConstruct script at least, or use some other preferred make system.
@daredemo
Hi. Sorry, iám not exactly sure how to tweak the PPC-build. ( Don´t use one anymore )
Normally the darwin-config.py is adapted to PPC out of the box.
If you had SVN-acces to the qdune-branch, you have the Blender-folder and the lib´s.
So all dependancies for OSXppc should be satisfied. Whats your problem?
I only changed the Libpath to darwin-intel for me and set some flags to false/true.
Heres my py, chaged to PPC in the first line. Python 2.5 is neccessary for this.
I don´t use user-config.py but configure the darwin-config.py for my needs.
Look:
This is most excelent! I am currently making a film production company title, and when this stuff is more mature (or blender gets a full featured rman exporter) I just might do my projects fully in blender. Fast motion blur, adjustable shading rate, micropoly displacements…all the things I miss in blender internal will come true it seems!
Its already heaps and bounds faster than BI or Yafray (which doesnt have any motion blur so for my uses its useless).
I would like to have BI option in the future though, the more the merrier.
Anyways, excelent work!
PS. The current motion blur implementation (temporal multisample) is a temp solution? I think most Rman renderers use a different algo?
I cant get the interpolation of normals working, I have a nice model to try out the micropoly displacement but cant get it to work without interpolated normals.
If it’s just camera blur, you can do this post pro in a compositor. I’m using this method on a project ATM. I just export the 3D camera to Shake and then apply motion blur by using the camera as a reference. I think Blender has a way of doing this kind of blurring too with comp nodes. It’s only linear and kinda limited to camera movement so it’s not as good as true motion blur but then e.g python exports are limited to linear blurs as Blender only samples on whole frames and that takes away the advantage of having true motion blur but it’s quicker to do it in post. I don’t know if QDune gets round that limitation.
Renderman uses multisamples though, it’s just that no matter how many samples you specify, the render time doesn’t go up by a great deal, though you kind of have to increase the pixel samples to avoid grain. It also interpolates linearly between samples, which I don’t actually think is a very good idea. I reckon most real-world cases would benefit more from cubic interpolation. This also keeps the file size down as you need fewer samples. This only really matters when it comes to deformation blurs though on high res models.
Not sure why you’d need to interpolate normals on a micropoly displacement or do you means that it’s not interpolating them? If you need explicit gouraud shading, you need to export the normals as varying.
@oxrules: I may have misunderstood you, but are you saying that blender’s vector blur is currently limited to camera movements? If so, I’d like to inform you that it’s not the case, every pixel has a vector I think, and all these vectors are used by the vector blur node in the compositor. Its quite convincing.
If you’re just saying that the qdune branch doesn’t have full vectorial blur, then I won’t say you’re wrong as I still don’t have a clue on what’s in that branch and what not!
This is extremely early work, only very basic integration yet, all done by Brecht btw, not me.
Currently you do indeed need vertex normals to displace meshes properly, otherwise all faces will be pushed apart by the displacement. Vertex normals are not implemented yet in the qdune/blender interface.
@simhar: don’t forget that there is no raytracing yet, and not even shadows either. C4D is raytracer isn’t it? Or does it also have a scanline mode or something? In any case, once qdune has raytracing (if ever), it will be almost certainly a lot slower.
Eeshlo,if I remember correctly,qdune has support for tif 32 bit(Blender support only the 8 bit tif,at least up to 2.43,I don’t know if the things is changed).It could be cool if 32 bit tiff can work,as it’s the 32 bit displacement standard format(zbrush,mudbox use it)
The fact that Brecht is helping with the intergration and Ton recognizing the project is pretty much a sure sign we’ll see this in Blender. (One of the Peach posts showed a picture of Brecht which Ton said he was hiding behind 2 micropolygons):yes:
I feel the same way whenever I think of modeling… 
this way there would be a way for each, aka. to each their own.
is now working on the code.