ANSWER POST
@Calus
calus wrote:About the camera matrix converter I'm curious,
why not take as input the world-matrix from the camera shape, instead of translate and matrix of the camera transform ?
(and the fluid shape also have a world matrix output
)
Not sure what you mean about the hypershade.
Since maya 2015 hypershade is the node editor with a special configuration, do you mean internally you still have to use the functions of the old legacy hypershade ?
Though in 2016.5 we still have to use the legacy hypershade for container node, containers are still not supported in node editor
( I guess containers in node Editor = Maya 2017)
Somehow I had in mind the world matrix of shape nodes is a null matrix. Obviously I was wrong!
Changed that, no need to have the transform nodes in the graph anymore!
For cameras and fluids and in the future any shape node.
No, I'm not using any hypershade specific functionality (legacy or not).
I was just wondering, if we want material and upstream nodes (textures, transforms etc. ) in the main node graph (as in standalone)
or we stop at the geometry level and have separate node graphs for the materials (like version 2 materials basically).
Just having an idea: The planned geometry collector nodes could be per assigned material maybe.
So we have each material once in the main node graph connected to the geo collector node,.
Each material can be edited there or in hypershade, however you like
and "assign material" from the context menu stays the assignment mechanism.
Need to look up container nodes, cause node grouping in some form would be nice sooner or later!
Again, just juggling design ideas for this part, any thoughts?
@renmaxhb? You seemed excited about collector nodes...
(but seriously anybody, not just
Calus or
renmaxhb )
p.s. the camera transform converters actual compute was really basic linear algebra, again more problems with mayas doc/API design XD
@Jolbertoquini
Jolbertoquini wrote:Quick question what about the render settings windows???
Would like to know more about it for older scenes and people who was using this before??
Well, most options from the render settings menu (render passes, kernels etc. ) are moved to the nodes they come from in octane standalone (render settings menu is just UI displaying these attributes).
So there is not that much left anyways.
Plus the Octane Live Account tab is out anyway, cause we have the new login splash screen.
And I don't see much reason to keep the render settings menu alive (for any octane settings).
Wouldn't it be nicer to have those options in the nodegraph in a seperate node as well,
since the new workflow is all about the node graph?
For what is left I mean, like the render devices tab...that could be a nice little node...
@gah5118
Scaling is on my list. We don't have a global way to scale octane to a specific unit, so I need to apply scale factors to all distances in the plugin.
@ivankio
Hi ,
you can link maya camera attributes to octanes, see below:
Just a problem there:
The connection with the maya camera shape attributes,
blocks updates from octane api for interdependent attributes of the thin lens camera, which are:
- TH_camera.png (7.33 KiB) Viewed 6788 times
When you move the sliders, you are able to see the updates from octane api live, like in the standalone thin lens node.
So I'll add, that those attributes, if connected, update their connected Plugs, so the octane api updates don't get lost.
Though you need to link the attributes by hand for now.
But thinking about an automatic link feature for some nodes, where the connections are unambiguous.
So for example these camera connections.
Current spotlights are a pain to work with because their directions do not even comply to their Maya transforms and there's a fuzzy relationship with opacity and alpha shadows (besides not showing in the viewport).
Didn't have a chance to look at that yet. But you mean maya spotlights?
Yes, feeding back the resolution, set in the new film settings node is on the list.
In general I have to keep an eye on synching settings, both available in maya and new maya2octane nodes.
WYSIWYG is what I want, as few hidden relationships as possible! Drives me crazy as well!
(if maya allows me: for example for fluids I have to grab the fluid shape when doing the other connections,
there is an attribute "out grid" of type fluid though, but don't know how to create a connectable attribute with the API, support ticket to AD on its way)
I like nodes for materials and animation, but I hope we can accomplish a lot using only the attribute editor/render settings alone. I'm guessing "ThinLensCameraNode1" would be a tab of the camera transform along side persp and perspShape instead of a frame inside perspShape like it is currently. ThinLensCamera does sound like a job for the shape node, but I guess a single additional tab is fine too (I suppose CameraTransformConverter1 is auxiliar and doesn't clutter the attribute editor).
As far as I can see, the attribute editor displays one tab for each node and shows tabs of connected nodes next to each other:
That's why I want to have separate nodes.
Don't like how much each maya cameras AE (Attribute editor) is cluttered with more octane sub and subsub menus in version 2.
Took me ages to find something.
Better have separate nodes and connect necessary attributes (more convenient with an automatic connection feature though XD).
Does for some reason not work when selecting the camera shape node (which is connected to the camera transform converter), no additional tabs are displayed!?
No idea why:
The render settings window will be less important, as I stated above. Just makes sense to go all nuts on nodes, since maya is build for dealing with them,
and yeah all attributes are scriptable than. So thats a plus I think.
Those loose kernels are also kinda scary. I hope they are easily accessible and not only buried inside the outliner with other hundreds of DAG nodes.
I agree. Nodes that are not connected to render target will be harder to find. While testing the node editor keeps them right where they are after loading the scene though.
It is quite possible to have unconnected nodes, like different maya2octane cameras or said kernels, so u can quickly change a configuration.
Any ideas how to keep them handy, except trusting the node editor to keep them where they are?
You could group them in the outliner. Still in my small test scenes its already cluttered there.
Of course 2D node graph has more space for organizing things than a 1D list, like the outliner.
So yeah, any ideas anyone on maya's capabilities on how to manage (find at least) unconnected nodes?
@limeforce
limeforce wrote:So update of status and roadmap, here we go:
Looking good Kai, thanks for the update! So, just to make sure: we'll be able to connect whatever Maya node outputs & inputs of a suitable type to the exposed pins on Octane nodes? Finally, that looks way more like proper integration than before!
I sure hope all the material inputs and texture nodes are similarly exposed. One of the more interesting things here for me is a more seamless integration with Substance, being able to connect substanceOutput.outColor (or any other texture+uv projection) directly to the Diffuse, Normal etc inputs on an Octane material would take a lot of unnecessary baking out of the equation and enable a way more playful workflow.
Keep fighting the good fight! Whenever it feels like you're drowning in the Maya API remember that the fruits of your labor will make a lot of people happy!
That is the plan!
Did not yet get to rework material nodes and anything upstream, but will do.
Well as long as the output is a single color (already sampled from a texture or just from a ramp for example) that should be fine:
Using ramp nodes as color dummies atm, for the volumes:
Actual textures are a different case, but I will get to that as well!
Integration with other plugins nodes is super interesting for me as well! Substance....FumeFX...we will get there!
Best,
Kai
I wasn't aware the IES rotation and opacity was kinda fixed. I stopped using them a long time ago because of the problems and no signal of willingness from Jim to look into them. (viewtopic.php?f=28&t=37454&p=165180#p165180)
