OTOY Forums

ello wrote:how about voroni noise types??

radiance wrote:Edit: regarding adding voronoi, I don't think we will be able to do it right now, or the kernel will get too large for older gpus, we will need to do some refactoring first.

Damn, I did a search first, but obviously I spelled it wrong

Yep, Voroni really sounded italian, while Gueorgui Feodossievitch Voronoï is definitely russian

what about a simple "add" node?

A time node. Anything that can be used to animate materials, really. That's the primary functionality missing from an exporter. Perhaps the time node is just an integer from the command line, or something like that which works together with an exporter to communicate to the scene material changes.

another thing that would be useful would be a converter node. For example to convert the output of a "MultiplyTexture"-Node to float.. so one could modify the power of a "Emission"-Node.. and much more possibilities

ello wrote:another thing that would be useful would be a converter node. For example to convert the output of a "MultiplyTexture"-Node to float.. so one could modify the power of a "Emission"-Node.. and much more possibilities

In this case the texture would have to be uniform and one-channel (ie. a pure BW color), otherwise it's not convertible to a single number. The problem that arises from this is checking if a texture is like that and what to do if it isn't. A float/int->texture converter is straightforward (and already planned), but the opposite is not true.

The power of emission is controlled by the texture you use in a texture emitter (black color = zero emit power), the power parameter is just a multiplier. You can modulate emission also by mixing two materials.

EDIT:.

IMO the float/int->texture conversion should happen implicitly (you can plug an float/int to a texture input). To avoid cluttering the graph with another node block, that does just that.

I would like to point out something slightly off-topic, but it's important for the material pipeline workflow in Octane 1.0 final. (also the devs working on nodesystem rewrite, are more likely to look into this thread )

* One thing that messes with your texture creation workflow is that you have to work in an lighted and tonemapped environment. When creating textures you want to work with pure colors, that are not affected by camera response, exposure, lighting environment, etc... - all of this will impact your final color and the results may vary wildly, depending on this settings. You can limit this by setting the tonemapper to linear and use "defaults", but your colors still depend on HDRI / daylight illumination. For texture creation an unlighted pure-color mode is more appropriate. Such mode would not even need the GPU and could work entirely on the CPU (hoping that such workflow would not impact performance).

* The material preview ball is not suitable for a texture preview - it has spherically distorted texture coordinates and because it's 3D (=intended for a lighted material preview) it gives you a poor preview of the whole texture. A 2D plane or surface is more appropriate.

* Additionally; when Octane will be aware of objects on the scene, it would be awesome if we could isolate an arbitrary object and use it as the material / texture preview object when creating materials. This way you would actually look at the object the material is intended for.

This is just something for the developers to keep in mind, when rewriting the nodesystem.

I hope I don't repeate anyone

- Invert, ceiling, floor can be combined by "set range". Takes 4 parameters: input lo/hi, output lo/hi.
Data is clipped by input lo/hi and then interpolated between output lo/hi. Clips, inverts, scales gamma.

Camera facing ratio would be great.

More and flexible procedurals would be too. Generic ones like image stacking, ngons, random lines noise.

IMHO the most useful node in any renderer I have seen is curves.
They replace clipping, invert, levels, color correction gamma and are efficient in terms of user interface.