Indigo Renderer 3.6.15 Beta Release

General News and accouncements regarding the Indigo render engine
User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Indigo Renderer 3.6.15 Beta Release

Post by OnoSendai » Wed Jun 05, 2013 3:58 am

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.

User avatar
Phoenix
Indigo 100
Posts: 158
Joined: Tue Jul 04, 2006 2:15 am
Contact:

Re: Indigo Renderer 3.6.15 Beta Release

Post by Phoenix » Wed Jun 05, 2013 10:38 am

Thank you Ono!

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

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Re: Indigo Renderer 3.6.15 Beta Release

Post by CTZn » Wed Jun 05, 2013 11:30 am

Thank you for this !

User avatar
juan_irender
Indigo 100
Posts: 251
Joined: Tue Jun 23, 2009 12:37 pm
Location: Spain
3D Software: Cinema 4D

Re: Indigo Renderer 3.6.15 Beta Release

Post by juan_irender » Wed Jun 05, 2013 9:42 pm

Thanks Ono, its a very useful update!

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Re: Indigo Renderer 3.6.15 Beta Release

Post by CTZn » Fri Jun 07, 2013 6:01 am

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)

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Re: Indigo Renderer 3.6.15 Beta Release

Post by CTZn » Sun Jun 09, 2013 3:02 am

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).

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Re: Indigo Renderer 3.6.15 Beta Release

Post by CTZn » Tue Jun 11, 2013 7:50 am

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 !
Attachments
wood_3d_01_draft.igm
(3.34 KiB) Downloaded 256 times
wood_3d_cats_01.png
An example of posOS() misbehaving on displacement. The denting on the albedo channel underlines the fact that shading happens after displacement, wich also prevents features matching.

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Re: Indigo Renderer 3.6.15 Beta Release

Post by CTZn » Tue Jun 11, 2013 8:54 am

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.

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Re: Indigo Renderer 3.6.15 Beta Release

Post by CTZn » Tue Jun 11, 2013 10:34 pm

I created a shared param with a blank space in the name and Indigo crashed.
Attachments
blank space.jpg
blank space.jpg (2.98 KiB) Viewed 8862 times

User avatar
juan_irender
Indigo 100
Posts: 251
Joined: Tue Jun 23, 2009 12:37 pm
Location: Spain
3D Software: Cinema 4D

Re: Indigo Renderer 3.6.15 Beta Release

Post by juan_irender » Wed Jun 12, 2013 1:35 am

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.

User avatar
fused
Developer
Posts: 3648
Joined: Fri Sep 22, 2006 7:19 am
Location: Berlin, Germany
3D Software: Cinema 4D

Re: Indigo Renderer 3.6.15 Beta Release

Post by fused » Wed Jun 12, 2013 2:22 am

CTZn wrote:I created a shared param with a blank space in the name and Indigo crashed.
Thanks for reporting, looking into that now.

User avatar
fused
Developer
Posts: 3648
Joined: Fri Sep 22, 2006 7:19 am
Location: Berlin, Germany
3D Software: Cinema 4D

Re: Indigo Renderer 3.6.15 Beta Release

Post by fused » Wed Jun 12, 2013 3:19 am

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 :)

User avatar
galinette
1st Place Winner
Posts: 923
Joined: Sat Jan 09, 2010 1:39 am
Location: Nantes, France
Contact:

Re: Indigo Renderer 3.6.15 Beta Release

Post by galinette » Wed Jun 12, 2013 7:50 am

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.

User avatar
juan_irender
Indigo 100
Posts: 251
Joined: Tue Jun 23, 2009 12:37 pm
Location: Spain
3D Software: Cinema 4D

Re: Indigo Renderer 3.6.15 Beta Release

Post by juan_irender » Wed Jun 12, 2013 8:38 am

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.

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Re: Indigo Renderer 3.6.15 Beta Release

Post by CTZn » Wed Jun 12, 2013 9:56 am

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).

Post Reply
24 posts

Who is online

Users browsing this forum: No registered users and 25 guests