@juanjgon Great work so far. It's coming out great, I think I will buy this in the near future, maybe on February/March.
By the way I have some suggestions on improving this Lightwave integration.
From what I've seen from your videos, you are currently implementing all the rendering and material features of Octane inside the node shader tree, you are somewhat mirroring the standalone Octane inside Lightwave creating nodes that represent each part of it, but integration with old nodes is somewhat missing.
Trust me, a perfect mirror of the Octane features is critical because it would make possible to build(later on) a perfect converter of any material library that will be created by users for the standalone Octane Renderer, and convert this to Lightwave material presets, enhancing workflow.
But there is a point to be taken into great consideration and that is with the current implementation we loose all the power of procedural texturing creation.
And this should be avoided also to make possible to convert old lightwave scenes into new Octane renderable ones.
Let's take Octane Texture Image for example adding an input node named Color would create a bridge between old scenes and the new Octane workflow.
I know that this somewhat creates a dependence on the LW nodes which are calculated by CPU and not the way Octane does(with CUDA), this would be a burden for the IPR renderer itself because for every frame(or Octane pass, this I don't know) it should wait for the CPU to calculate the node, this could be fine for some textures but it could be not for others, ie:. Occlusion shaders...etc..
This could be implemented like this (Simply adding the Color input inside the Octane Node) or
This could be done (as the only way or as an alternative) by creating a conversion node, that actually bakes in memory/or to a file(temporary or not) and output an Image and a UVMap out of the color and texture informations.
Some stuff to notice:
Lighwave internally works with a gamma of 1.0 which is fine for all the 2d procedurals it creates, an exception should be made for downloaded textures which should be DeGammaed if used together procedurals to get consistent results(which is expected to render inside a physical rendering engine, still this should be only considered only a workflow issue for artists). So there is no need to take Gamma into any account in the conversion node, if there is a layer with a 2.2 Gamma texture, that should be a problem of the Artist to degamma it before mixing with other procedurals, anyway.
The texture space definition should be easily converted to an UVMap, if it's not an UVMap already.
Tiling informations should be converted too.
The node should have a Bitmap texture resolution inside, for a perfect conversion.
The conversion should happen per frame because it is important for animated textures and textures that work in 3d and World Coordinates.
Nodes that contain multiple texture layers(with different texture spaces) should be somewhat disassebled into another Conversion Mixer Node, that in the end goes back to one texture for the Octane Texture Image node.
This would improve the range of usage of the plugin itself and would make a lot of people using DPKit, iFW and other procedural packs very happy.
I think you already thought of this stuff, these are just basic ideas on the matter, probably you can create even a better implementation.
IMHO this request has a huge importance to the LW community, I would have not asked this if it wouldn't have been like so.
Hope you will think about it as soon you solve your development priority issues.