OctaneRender 2019.1 LightWave beta build 2019.1.0.2 RC3

[juanjgon]

Hmm, I think that this feature is not available yet, or at least I can't find it even in the latest 2019.1 Standalone builds.

Thanks,
-Juanjo

[pixym]

Okay Juanjo, Thanks for this usefull information.

[Pavlov]

Hi,
just installed it, seems fine but if i try to set a material from menu i get this:

Any idea ?
Thanks

[AndyM1969]

Add the material from the nodes, not from the drop down menu.

[juanjgon]

Hi,
just installed it, seems fine but if i try to set a material from menu i get this:

Hi,

I've been checking this issue and it seems a problem related to the new LightWave 2019.1 version. In LightWave 2019.0 all seems to work fine. It could be a bug on the LightWave side, but I'll investigate it.

Thanks,
-Juanjo

[scooternva]

Have there been any improvements to the user interface for OSL nodes in LightWave's node editor? Simple example: the Mandlebrot example (https://docs.otoy.com/osl) in the online documentation. In standalone OctaneRender there are sliders for the numeric inputs. In LightWave, all you get are the connection pins (which ignore the string labels in the function declaration and expose the underlying variable names instead). This is especially a problem with enum-type inputs (e.g., "mapper"), and it makes using string inputs (e.g., to select a filename) impossible.

[juanjgon]

Have there been any improvements to the user interface for OSL nodes in LightWave's node editor? Simple example: the Mandlebrot example (https://docs.otoy.com/osl) in the online documentation. In standalone OctaneRender there are sliders for the numeric inputs. In LightWave, all you get are the connection pins (which ignore the string labels in the function declaration and expose the underlying variable names instead). This is especially a problem with enum-type inputs (e.g., "mapper"), and it makes using string inputs (e.g., to select a filename) impossible.

Not yet, sorry. I want to work on it at some point, but the ancient LightWave nodes architecture doesn't make this kind of features easy to implement at all. Probably one first step could be to add a custom node for the string parameters, at least to avoid this limitation.

Thanks,
-Juanjo

[scooternva]

It would also be nice if OSL nodes

1. did not lose their connections when you copy/paste the LightWave surface or the LightWave Compound node that contains them
2. did not require a recompile when you copy/paste the surface/container node
3. outputted more than one texture (or even better yet, outputted one or more materials).

I've got a complex node network that I'm leveraging the OSL node for to vary the appearance of an object depending on various factors that are inputs to the OSL node. Having the variances in one *.osl script makes it SO much easier to experiment with the combined effect vs. having to click, click, click all over the place to adjust node attributes one at a time, but it's aggravating having to recompile the OSL nodes and carefully re-establish the incoming connections each time that a surface or Compound container node is copy/pasted to a new surface. Native LightWave nodes don't do this... not even regular OctaneRender nodes lose their incoming connections when copy/pasting. Just a thought!

[juanjgon]

Yeah, all these problems are related to the ancient LW nodes architecture. To build or rebuild a node, you must delete all the inputs and add them again, so all the pins are disconnected. I'm not saying that this doesn't have a solution, but it is not easy at all. I'll try to work on it after finishing all the work related to the spectron lights, that is now the only main Octane 2018/2019 feature missing in the plugin, so it has top priority.

Thanks,
-Juanjo

[scooternva]

Spectron definitely should have top dog status; no worries! I'm a .NET system architect by day and love scripting languages, so I did the OSL thing more to see what was possible with the technology and whether it really saved me any time vs. directly editing the node attributes one at a time. In the end, I decided that it wasn't worth the extra bother, especially since it also introduced an unusual dependency for my objects that isn't versioned and still seems to be in a state of flux--I really didn't want my model leaning on a feature that might change drastically with the next release! Thanks.