OctaneRender® 1.025 instancing preview test build

[matej]

the sliders are too coarse for small refinements.

Yeah, all the sliders that deal with translation are useless, because you move the slider one micron and the camera/object moves a few kilometers... Some way to scale down the influence (Blender - > holding shift) would be needed.

Maybe it is possible to use the unused matrix values for color information

An interesting idea, but not a good solution imo:

- that would mean mixing "geometry" & shading tools together = not really a good workflow paradigm, more like a hack
- changing colors would need a re-export of the scene
- (diffuse) color is just one of the many material params that constitute the end result

The right solution for the problem ("how to vary material properties across instances") is by having powerful texture mapping tools. By this I mean Octane being able to map textures (any textures not just procedurals) in various coordinate spaces (global, local, object, UV) and automatic modes (flat, cube, sphere, cylinder). In the case of instances a global coordinate mapping would already help, though its not suitable for animations if the instances move around. Thus we would need an "object" coordinate space, where the coordinate origin would be defined for example by the first / original instance of the group - the texture space for all the other instances would be derived relative to this instance. This would work with animated instances.

In any case we need more texture coordinate spaces / automated texture assignment solutions. I hope that now with the engine re-write we could get those mentioned (global, local, object coordinate spaces & (the most important thing!!) per texture coordinate assignment).

[face]

the sliders are too coarse for small refinements.

Yeah, all the sliders that deal with translation are useless, because you move the slider one micron and the camera/object moves a few kilometers... Some way to scale down the influence (Blender - > holding shift) would be needed.

Maybe it is possible to use the unused matrix values for color information

An interesting idea, but not a good solution imo:

- that would mean mixing "geometry" & shading tools together = not really a good workflow paradigm, more like a hack
- changing colors would need a re-export of the scene
- (diffuse) color is just one of the many material params that constitute the end result

The right solution for the problem ("how to vary material properties across instances") is by having powerful texture mapping tools. By this I mean Octane being able to map textures (any textures not just procedurals) in various coordinate spaces (global, local, object, UV) and automatic modes (flat, cube, sphere, cylinder). In the case of instances a global coordinate mapping would already help, though its not suitable for animations if the instances move around. Thus we would need an "object" coordinate space, where the coordinate origin would be defined for example by the first / original instance of the group - the texture space for all the other instances would be derived relative to this instance. This would work with animated instances.

In any case we need more texture coordinate spaces / automated texture assignment solutions. I hope that now with the engine re-write we could get those mentioned (global, local, object coordinate spaces & (the most important thing!!) per texture coordinate assignment).

Let me say it with other words.
We can use the textfield and add 4 other values at the end of the matrix for the color in the form of RGBA.
Then a new section for the variations, where you can choose the blendmode for the whole instances (add, subtract, multyply, etc...) and the material (diffuse, glossy, etc...).
The alpha value from the RGBA will be the mix value.

To change the color values, you must re-export the scene, there is no other chance to change 1mio or more values.
Your idea with the mapping coordinates is good, but have nothing to to with the instances itself, only with the source meshes.

face

[matej]

We can use the textfield and add 4 other values at the end of the matrix for the color in the form of RGBA.
Then a new section for the variations, where you can choose the blendmode for the whole instances (add, subtract, multyply, etc...) and the material (diffuse, glossy, etc...).
The alpha value from the RGBA will be the mix value.

I understood that. I just think that tying material data inside geometry data is not a good implementation (but it can be a temporary half-solution).

Say for example you have a carpet with 1 mio. strand instances. With your implementation every strand would have an additional color (probably diffuse, but the value could be interpreted anyhow) parameter, together with alpha parameter, that would govern the amount of blending with some base color. With this you can achieve different diffuse color look across the carpet, but that's it. This implementation also ties the shading to the original 3D app, where you wold have to specify the color of instances -> which I think is wrong, as shading should happen entirely in Octane (this concerns mostly the standalone version).

The right approach to vary material looks (not only one material parameter, but all of them -> specularity, bump, transparency...) across the carpet instances would be to use a texture (procedural or image) mapped globally or "object local" (local to the original object / instance) to modulate different material parameters or control mixing amount between different shaders. This way you can control any parameter not just some predefined & stored in a transform matrix. You also don't need to re-export anything, just use a different texture / mapping, if you want to change the looks.

If the devs are for such an "inside matrix data storing" (cause yes, that last vector is wasted data space), then I'm also for it, I mean anything is better than nothing. But I strongly feel that we need more texture mapping tools, because in the end this is what gives flexibility in material creation (and that's how other renderers / 3D apps do it).

EDIT:
Also if you decide to put anything different than 0,0,0,1 as the last vector, the whole internal calculations would have to be adapted to this, because you cant use such a matrix for straightforward 4x4 matrix operations anymore.

[ROUBAL]

But I strongly feel that we need more texture mapping tools, because in the end this is what gives flexibility in material creation (and that's how other renderers / 3D apps do it).

I totally agree, as well as more procedural textures. I asked some time ago for a good Cloud procedural texture (like the one in Blender), that is really missing in Octane, but I got no response.

The only current procedural alternative in Octane is Turbulence, that gives sharp edges (like hammer strokes) and is not good at all for bump on metal surfaces for example. I used it as a temporary solution on the model I am currently working on, and it is not convenient as you may see :

http://3d-synthesis.com/52-AEC-Routemaster.html

[pixelrush]

Well this texture mapping sounds like the most comprehensive/flexible solution but how does that help something like the leaves on a tree? or a school of tropical fish? ie 3d space. Sure this works if the object has a skin to refer a UV map to like the hairy dragon of @face's but what if it doesn't? How about the situation where I said before where you have many hanging baskets say positioned around a multistorey hotel's balconies and you just want the flowers to be a different colour. Or another situation where you have a scattered crowd and want random shirt colours. These situations dont tend to lend themselves to texture control. What if too you then decide to move the instance with a transform node and it then changes colour as the result of the movement relative to the texture. Shouldnt these be independant? Can't we still have a random variation tool? Forgive my lack of technical understanding or weak reasoning but why does the whole thing need to be reexported for this? In fact don't we just need a panel a bit like the stereo glasses one where we can nominate 2 colours that are optionally to be the range or the alternate colours for the instances and a slider for bias toward one or the other?

BTW good to see some active forum participation and debate coming back

[matej]

...as well as more procedural textures. I asked some time ago for a good Cloud procedural texture

Yep, + a voronoi noise for organic stuff, hammered metal, "speckled" paint...

Considering our limitations with VRAM, re-use / better use* of texture data and powerful procedurals should be top priority.
(* flexible mapping techniques generally allow you to do the same quality job with less texture data)

[matej]

@pixelrush, here's a fast example done in Blender.

I used hair with object visualization (a cylinder). You paint over the emitter UV and that texture can represent anything: from diffuse color to a mask for shader mixing. The most important part is the "mapping" panel in the "textures" window. Blender has a bunch of different texture coordinate sources and projection options. Octane lacks most in this field.

In this particular case the texture coords are defined by the object selected (the original strand object used for visualization), if you move that object around, the texture space moves with it (the strands move "though the texture"), but if you move the object and the emitter everything stays put. The strand instances take the color of the pixel "under them".

Octane could use the same mapping techniques - no need for additional data, just a texture mask and different coordinate spaces. Of course that empty vector could be used to store some data, but I would rather use texture mapping for such effects.

Basically we need:

* global coordinate space (in Blender called Global), where world (0,0,0) is the origin. This is how Octane procedurals are mapped right now (but you cant use it for image textures). This space is mostly unusable for animations if the object moves.
* local coordinate space (in Blender called Generated), where coordinate origin is the object origin.
* object coordinate space (in Blender called Object), where the coordinate origin for some texture mapping is defined by some other object - as is the case in my example)
* UV space, which we have (but only for image textures). We should be able to have multiple UV sets per object.
* possibly others (window / camera)

This, coupled with the ability to set a coordinate origin for each individual texture separately (absolutely necessary), should give enough power to vary the material parameters across a bunch of instances, even in animations. In the case of instances, the "object coord space" where origin is defined by some object (possibly the first instance) is the most useful imo. We could call this "instance coord space".

There is also the option of instances having different material indices = different materials inside an instance group. (which material an instance uses could be specified exactly the same as in my example - with a mask texture)

I cant think of solutions for all your proposed problems (but then again Otoy doesn't pay me to think, ups!, doesnt pay me at all ), but this should solve at least some. In any case, more flexible texture mapping is a separate problem than instances and something that we should have anyway. (but can be used to solve some instance related questions)

[face]

The problem is, you are limited on a texture which can´t generate dynamicly.
You can make nearly the same with colors and this is dynamic.

Have made a test in Softimage. I read the color information from a underlying plane which have multiply texture maps.
I make a falloff from a null and each particle and can then blend betweent the two colors from diffent maps.
The plus is, i can animate the null and become different results which are dynamic...

face

[matej]

@face, ok, I see what you are doing there. But in Octane we cant even render that "instance carpet" with one or the other texture you used. Exactly because we don't have the proper texture mapping tools. (unless all that geometry is real geometry in your 3D app and you UV-unwrap it - but most likely this is not the case, cause so you loose al the flexibility of particles / instances)

So, to render your example in Octane both things we are talking about are needed: a way to map textures in a "instance local" space and some additional data (falloff from the empty) to blend the two. The question is how that additional dynamic data should be passed to Octane? It could be embedded in the transformation matrix, but that would limit you to "one texture" (one 2D array of 4D vectors). Unless the 4D vector would be interpreted not as RGB+A, but 4 separate grayscale masks, that would give us 4 "textures" - a bit more useful data to work with, hm...

[smicha]

This is the greatest news since I bought Octane!