OTOY Forums

You can stick to this "arrogance" and ignore all the logical comment/remarks I just made.

Also since we do not know each other, I d avoid characterisations.

Cheers

well sorry but you did write 2 new posts while i was answering to your first post. so couldn't answer to those.

- When something is called "vertex attribute" and accepts "point attributes" is simply wrong UX and super confusing.

the problem is not octane for houdini related imo. classic dcc's like maya / blender etc ... need to store per point user data as a vertex attribute.
if you want to export user data from houdini to arnold for maya, this is the same logic you have to promote point @Cd to a @vertex float 3 color to make it works.
on top of that the vertex color node is a standalone node, juanjo has implemented it exactly the way it is in standalone, so it's not a houdini issues.
i do find that having a very strong fidelity between nodes and naming between octane standalone and houdini plugin is a GOOD thing.
if you want to have a point color data nodes you have to ask this to the octane core team on the general discussion forum.
i guess they will answer you that in most dcc's point data will not exist, as most dcc's again need to store attrib per vertex for polygonal mesh ( maya , blender ... )

vray :
https://docs.chaos.com/display/VMAYA/Ho ... c+Workflow
arnold :
https://www.sidefx.com/forum/topic/55208/

- When I have to promote prims to vertex so i get prim attributes

see answer 1. prim attributes doesn't exist in many dcc's. the only thing that you can see is vertex attribute for geo and point att for particles. octane is a cross dcc's engine so it has to choose the common denominator to share data.
if you export houdini prim attribute to arnold for maya or in blender you have the same problem. again it's not octane related imo.
if you want clean / beautiful full featured direct access to houdini data tree, karma and mantra are the way to go.

- When i use rppk maps to get attribs (whatever this is called).

This is legacy workflow now, you don't need to use this anymore, you should be able to read @att on geo / points / cvs directly.
juanjo did it to bypass the lack of feature in octane core. it did this pre 2020 to allow us to bypass octane limitation.

what octane CAN'T do that other engine can do is to transmit a perpoint attributes to an instanced objects. that's a limitation, but you have tricks and hacks to bypass this.

When I repeat twice that exposure slider shouldnt be from 1-1000 and i dont even get a reply, what does that say to you?

i am not sure i get exactly what you are talking about ? exposure in render target ? because houdini match perfectly standalone here ? could you be more precise about this exposure problems ?

thanulee wrote: Afaik already the c4d developer is helping rebuild the ipr in H if that says something to you.

It doesn't matter, but this is not true. The new Qt5 IPR system of the Houdini plugin has been developed by myself from the ground up, without any additional help

Thanks,
-Juanjo

thanulee wrote:Also what is "ready solution"?Not having exposed a single color in Dome light ? (which dome light doesnt even exist?)

The number of possible UX/GUI combinations of all the Octane features inside a single RenderTarget HDA are almost unlimited. Of course, it is possible to add this feature to the included HDA, and of course, it is also possible to include an additional HDA and let it work as a dome light. This is the good news, in the Houdini plugin, almost everything is possible. The bad news is that I add all these features when I can, and they depend on the number of requests about them, so I have added them to my TODO list to try to have them available later this year.

Thanks for your patience,
-Juanjo

thanulee wrote:When I repeat twice that exposure slider shouldnt be from 1-1000 and i dont even get a reply, what does that say to you?

Sorry, probably I missed this request. I've just replied to one of these posts, although I've seen it only once, probably my fault.

-Juanjo

thanulee wrote: - When something is called "vertex attribute" and accepts "point attributes" is simply wrong UX and super confusing.
- When I have to promote prims to vertex so i get prim attributes
- When i use rppk maps to get attribs (whatever this is called).

In Octane, both "vertex" and "point" attributes mean more or less the same in the sense that it only has vertex attributes, so the point attributes are extracted as vertex automatically. BTW, promoting prim to vertex attributes is something common in other renderers. Even the other well-known GPU render has the same limitation and workflow

The .ppm maps to render attributes are the workaround that I've found to avoid the lack of vertex and attributes, an old Octane limitation that now is only needed while rendering instances. This could be improved at that time, of course, rendering an internal map with this data, but now that Octane has this limitation almost solved, it makes no sense to work more on it.

Thanks,
-Juanjo

juanjgon wrote:

thanulee wrote:Also what is "ready solution"?Not having exposed a single color in Dome light ? (which dome light doesnt even exist?)

The number of possible UX/GUI combinations of all the Octane features inside a single RenderTarget HDA are almost unlimited. Of course, it is possible to add this feature to the included HDA, and of course, it is also possible to include an additional HDA and let it work as a dome light. This is the good news, in the Houdini plugin, almost everything is possible. The bad news is that I add all these features when I can, and they depend on the number of requests about them, so I have added them to my TODO list to try to have them available later this year.

Thanks for your patience,
-Juanjo

Thank you! this is definitely needed as its very confusing to manipulate a sun/sky and domes on mat context. These are all lights.

Its not unlimited parameters we need to have access, but few basic things to have our lives easier. I will come back on this on a request with more detail. These QOL are what is missing from the plugin.

But definitely, we need to port all those in a dome light/sun&sky in obj level. As RS has and then we can combine multiple domes one eg for bg one for lighting. This is very typical workflow.

Re: vertex and point

It wouldnt hurt to have an extra node called "Point attributes" in materials, same as in octane tag in obj level.
And to have a checkbox in there about packed instances where u check it and under the hood loads this ppm map.

As H is so explicit about vertex vs point, the new user needs to have this info super clear.

This would take away a lot of the confusion. Again i ll get back in a request about any of these so its clearer for u. Thanks