Indigo Renderer Forum

This is a Beta release.
If you spot any bugs or problems, please make a post about them in this thread.
Thanks!

Indigo for Windows 32-bit:
IndigoRenderer_3.6.15_Setup.exe

Indigo for Windows 64-bit:
IndigoRenderer_x64_3.6.15_Setup.exe

Indigo for Linux 32-bit:
IndigoRenderer_v3.6.15.tar.gz

Indigo for Linux 64-bit:
IndigoRenderer_x64_v3.6.15.tar.gz

Indigo for Mac OSX (10.6 - 10.8 ):
IndigoRenderer3.6.15.dmg


Indigo RT for Windows 32-bit:
IndigoRT_3.6.15_Setup.exe

Indigo RT for Windows 64-bit:
IndigoRT_x64_3.6.15_Setup.exe

Indigo RT for Linux 32-bit:
IndigoRT_v3.6.15.tar.gz

Indigo RT for Linux 64-bit:
IndigoRT_x64_v3.6.15.tar.gz

Indigo RT for Mac OSX (10.6 - 10.8 ):
IndigoRT3.6.15.dmg

Changelog:

3.6.15
* Added support for bump-mapping based on posOS().
* Various optimisations.

Thank you Ono!

And I guess it's time for a new stable soon. ;o)

Thank you for this !

Thanks Ono, its a very useful update!

Bidir returns black or something on my rig. All other modes ok.

Haven't been on the latest stuff, tinkering with MtI: shared shader textures(!), shared params, shader textures and params are in. I'm left with the shared code routine to write 8)

CTZn wrote:Bidir returns black or something on my rig. All other modes ok.

I should clarify: Albedo's are returning black with bidir. It's obvious but someone had to tell.

edit: and it may be worth signaling that this kind of thing can happen with an odd beta release number (no kidding).

The shader that returned a black albedo on bidir is now functionning properly with this mode... nvm I guess.

posOS() works right for bump mapping now, unlike with displacement. It should be at my reach to fix this on the shaders side but this prevents using shared code somewhat.

Also on displacement, it is happening before shading wich is relevant in several cases, but not for 3d woods for instance. This kind of feature-based shaders would require to divide and displace the already shaded base mesh.

This later way is correct and expected if I refer to 3d editing applications. In terms of shading, displacement is always a consequence, never a cause if that makes sense.

Meanwhile, bump is doing good, positively enough for most purposes !

If the object shaded and displaced using posOS() is an organic character, it makes sense to deduce its shading from a fixed, invisible (base) mesh.

In maya this feature is called a texture reference object:

You can create a texture reference object for the selected surface to lock a 3D texture or projected 2D texture to the surface. As the surface animates or deforms, the texture stays with the surface, producing a very natural looking result.

I created a shared param with a blank space in the name and Indigo crashed.

CTZn wrote: Also on displacement, it is happening before shading wich is relevant in several cases, but not for 3d woods for instance. This kind of feature-based shaders would require to divide and displace the already shaded base mesh.

Hi, CTZn.
Well, the usual order in a pipeline rendering wich supports displacement of P values, are: first displace, then shade!
If you displace the surface, new normals produced by the displacements needs to be computed, so shading will go after the surface displacement...

Ciao.

CTZn wrote:I created a shared param with a blank space in the name and Indigo crashed.

Thanks for reporting, looking into that now.

fused wrote:

CTZn wrote:I created a shared param with a blank space in the name and Indigo crashed.

Thanks for reporting, looking into that now.

Fixed for the next release

juan_irender wrote:

CTZn wrote: Also on displacement, it is happening before shading wich is relevant in several cases, but not for 3d woods for instance. This kind of feature-based shaders would require to divide and displace the already shaded base mesh.

Hi, CTZn.
Well, the usual order in a pipeline rendering wich supports displacement of P values, are: first displace, then shade!
If you displace the surface, new normals produced by the displacements needs to be computed, so shading will go after the surface displacement...

Ciao.

You can compute new normals, you do not need. And there are better techniques than re-computing them from the displaced mesh.

galinette wrote:

juan_irender wrote:

CTZn wrote: Also on displacement, it is happening before shading wich is relevant in several cases, but not for 3d woods for instance. This kind of feature-based shaders would require to divide and displace the already shaded base mesh.

Hi, CTZn.
Well, the usual order in a pipeline rendering wich supports displacement of P values, are: first displace, then shade!
If you displace the surface, new normals produced by the displacements needs to be computed, so shading will go after the surface displacement...

Ciao.

You can compute new normals, you do not need. And there are better techniques than re-computing them from the displaced mesh.

Hi Galinette.
At least in REYES architecture/RSL this is the way to go since 1988. In fact, when you write a RSL displacement shader (or bump, for that case), you *must* specify a normal recalculation after you finally modify the point position... But obviously, in rendering architectures evolution from prior achievements are high priority, much more today, where raytracing are the most commonly used rendering algorithm and optimizations are mandatory.

Hey guys, I'm not even going into such historico-technical matters.

If I want to use a dist( coords, voronoi3d( coords ) ) wich does circular gradients, to color and displace a horn say, by the time the mesh was displaced the volumetric point that will shade is left behind. Fail.

I'm not invalidating the other method; I'm requesting a switch for displacement to happen before or after shading, because I'm used to the other way (just as with 2d textures), regardless of optimization concerns.

The other request that may allow the said flexibility are texture references objects (see my post of the 10 Jun 21:54).