General News and accouncements regarding the Indigo render engine
-
Phoenix
- Posts: 158
- Joined: Tue Jul 04, 2006 2:15 am
-
Contact:
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)
-
CTZn
- Posts: 7240
- Joined: Thu Nov 16, 2006 4:34 pm
- Location: Paris, France
Post
by CTZn » Wed Jun 05, 2013 11:30 am
Thank you for this !
-
juan_irender
- Posts: 251
- Joined: Tue Jun 23, 2009 12:37 pm
- Location: Spain
- 3D Software: Cinema 4D
Post
by juan_irender » Wed Jun 05, 2013 9:42 pm
Thanks Ono, its a very useful update!
-
CTZn
- Posts: 7240
- Joined: Thu Nov 16, 2006 4:34 pm
- Location: Paris, France
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)
-
CTZn
- Posts: 7240
- Joined: Thu Nov 16, 2006 4:34 pm
- Location: Paris, France
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).
-
CTZn
- Posts: 7240
- Joined: Thu Nov 16, 2006 4:34 pm
- Location: Paris, France
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
-
- 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.
-
CTZn
- Posts: 7240
- Joined: Thu Nov 16, 2006 4:34 pm
- Location: Paris, France
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.
-
CTZn
- Posts: 7240
- Joined: Thu Nov 16, 2006 4:34 pm
- Location: Paris, France
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 (2.98 KiB) Viewed 8865 times
-
juan_irender
- Posts: 251
- Joined: Tue Jun 23, 2009 12:37 pm
- Location: Spain
- 3D Software: Cinema 4D
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.
-
fused
- Posts: 3648
- Joined: Fri Sep 22, 2006 7:19 am
- Location: Berlin, Germany
- 3D Software: Cinema 4D
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.
-
fused
- Posts: 3648
- Joined: Fri Sep 22, 2006 7:19 am
- Location: Berlin, Germany
- 3D Software: Cinema 4D
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
-
galinette
- Posts: 923
- Joined: Sat Jan 09, 2010 1:39 am
- Location: Nantes, France
-
Contact:
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.
-
juan_irender
- Posts: 251
- Joined: Tue Jun 23, 2009 12:37 pm
- Location: Spain
- 3D Software: Cinema 4D
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.
-
CTZn
- Posts: 7240
- Joined: Thu Nov 16, 2006 4:34 pm
- Location: Paris, France
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).
Who is online
Users browsing this forum: No registered users and 33 guests