i think we need one more section in houdini, and its for handling data organization/reference/manipulation EDIT: handling strings, i think is more accurate to say "parameters data" (could be paths, strings, but also numbers, math, reading paths from files in disk too, etc etc). imagine this. DAOPs (data operators (?))

you have a box, its height depends on some other data + the porcentage of other data + a multiplayer for some reason. you end up with a lot wiring jumping from one node to another, trying to understand long ass string/funtions on parameters, etc.

maybe if we got one more context for this kind of stuff like: you go to DAOPs, some sort of VOPS(with things like reading txt files on disk or whatever (kind of PDG stuff)) well, you open this context and you have a "string" node, to create a variable name for the "height" attribute we need,then we just hook up a couple of "import parameter" node, with some math nodes like in vops to make the logic, then we just export this variable "height" and we just put something like "@var_height" in the box's size parameter. super clean and easy to read/understand all the logic behind the "height" of the box.
Could be a good context for Strings manipulation(the pain of paths writing ffs) easily solved by string nodes with things like "add", "substract", "find string", "divide by caracter", idk... endless posibilities.
then we just export something like a global variable to use it in any part of the software. like @var_variablename


hope it makes sense, sorry for my poor english.

i know its possible to do it by saving that data on attributes or whatever, but its not clean and for some things like reading data from disk it could be easier than using python or spaguetti wiring/referencing.

stop this madness of long ass funtions/parameters text in tiny windows and make it more houdini's way of doing things, a couple of nodes and wires.

EDIT: this could be a replace for those $F%4==0 kind of (function?). imagine just entering this new context and dropping a "loop count" that give you a value in a range, with some other node like "skipping every x frame", or things like that. maybe this could open a door for more procedural animation and making handling instances with custom animation offsets more easy.

EDIT: other situation where this could be usefull, RigPose, god, the amount of time you spend locking parameters, referencing etc etc.
imagine just going to DAOPs droping a "import parameters node", it brings all the parameters in the rigpose node (in a string-list type of data) then we just find every parameter with "scale" in its name, group them, and with the "lock parameters" node, we specify the parameter group name, lock all selected. easy. clean.
Limit, clamp, remap, values. for animation could be amazing, like, putting just 2 keyframes, linear, and importing that parameter into DAOPs, then remapping, adding fxs. like chops but in a VOPs style and working directly with parameters strings. no attributes, no geo.

idk, i think it could be awesome.

Other cool things:
-AI for node recomendation, vex code, etc.
-smart autowiring
-better animation-wise features. Maybe more procedural animation?
-Node bubbles and groups ("allways on top" kind of thing) yes, like social app's chats (whatsupp, messenger, etc). for big proyects is a must. you easily spend 30% of your time just trying to find specifics nodes back and fourth, i know there is the CTRL+Number thing, not the same.

I’m trying to understand your idea. Maybe we already have the seeds of these data-nodes with “ Attribute from Parameters” and Attribute Adjust Dictionary” SOPs? You’re thinking of expanding on these?

Are you referring to something like the context option editor in Solaris? where you can declare global variables and use them in any parameter.

no.
right now its Keyboard/Mouse -> parameters -> nodes doing their thing

i want Keyboard/Mouse -> NewContext ( that outputs values to later use them in parameters (no attributes, no geo, just string datatypes) -> parameters -> nodes doing their thing.

for things like string manipulation, (find characters, divide by character, erase part of a string, enum, etc)
functions/nodes that output a value of 1 every X amount of frames. ($F%3==0) and all kind of logic for timeline depended values.
nodes that can read amount of files in a folder for example, for texture files. to make things like wiring textures easy, clean and fast.

im literally asking sidefx to make nodes for node's parameters. lmao. but i mean it.

all the logic that goes into those tiny windows in node's parameters basically, transform that into a VOPs kind of Context but centered in string manipulation/names/paths manipulation/some basic math for numering stuff/ hability to edit a node(same way we do it to create new parameters, blocking parameters, etc) but in a node-base system.


instead of a hundreds > right click in scale parameter -> lock parameter. to lock scale parameters in a RigPose for example.
why not (in new context) > "import parameters from node" node -> "group parameters by string match" node to find every parameter with "scale " in the name -> "lock parameters" node, pointing at the group of parameters, "lock selected".

to wiring textures could be something like: "array from files" node to make a list of the names of files in a folder > "if match" node, if "normal" in the name then -> take its file path string -> export it to a global string variable @var_normal or maybe we can just set it from this context like -> "set parameter value" node to set to 1 the PrincipledShader's->texutures->basecolor_useTexture=1 -> and then set the path to the file in the parameter:basecolor_texture=file's path.

then put all that into a HDA, every time you need to load 5 or 6 textures per material, just drop that HDA, point it to the folders, right click->cook. all ready.

beautiful, easy and procedural. like houdini.

i know its achievable with python, but nodes and viewport interactivity its the way.

what if its like a node-base-python-states kind of context... maybe PYOPs (Python operators)? wow that could be amazing.

Have you checked out the parameter spreadsheet? Some of that you can do there. I agree though, it's an interesting idea.

Midphase
Weird to me how damn religious people get about software......damn SOFTWARE!?!?

well, i mean, it is an improvement over holywars around render engines from last decade

nickfr

d3dworld
Greetings,
Everything said in this thread did a great job of pushing me away and killed what motivations left in me to start learning.

Kind regards.

Houdini isn't hard to learn. Even I can produce great images, sims and renders. And I'm just a simple photographer. Just take your time and have fun. That's it.

Yes, not hard at all, just unnecessarily time consuming in some places to work with and unreliable in other places, and if you don't have deadlines then it's great.

zf3d
houdini usd lop Currently, it's too easy to die

Hope to be stable, stable, and more stable, replacing Clarise

Houdini is souls-like game, no hand holding

hMonkey
Houdini is souls-like game, no hand holding

And once you get the hang of it, most other games are a letdown.

hMonkey
Yes, not hard at all, just unnecessarily time consuming in some places to work with and unreliable in other places, and if you don't have deadlines then it's great.

To me this is not actually a Houdini specific issue. Alright, there is always aomething to update and simplify sure. It is a matter of priorities. However I’ve used Imagine, Strata (90’s), 3DS Max (early 21th century), Maya (appx 2006-2012), Blender (2012-still), and now slowly learning Houdini. Learning anything is usually very time consuming. Also, during production (yes, been there) you don’t have much time to try anything untested. Except maybe if you work in RnD outside of production.

However, to be fair, even if you work in production you can set aside 30-60 min each day to try and learn one or two new things. Whatever you achieve you can save or export (or just drag your network to a shelf). It is a challenge to plan and use your time and energy.

Will Karma be fully integrated like Arnold in Maya or Cycles in Blender.
At now, it's very user unfriendly.

tomtm
Will Karma be fully integrated like Arnold in Maya or Cycles in Blender.
At now, it's very user unfriendly.

Karma is a USD based Render Engine with Hydra Viewport Integration. In other words you could Integrate Karma in every Software that supports Hydra and USD and it feels like a native Renderer. Other Render Engines will feel the same as Karma in Solaris if they Support the USD / Hydra / MaterialX Specs.
Surly some Functionality is missing in Solaris, Karma needs some more Features but i am 100% sure H20 will be a awesome Release.

tomtm
Will Karma be fully integrated like Arnold in Maya or Cycles in Blender.
At now, it's very user unfriendly.

Which renderer is better integrated? Karma works with every version of Houdini, there’s no weird version lock, nothing to install and license separately. There’s pretty complete documentation on every feature and it works with the rest of Houdini. Apart from a few missing features and the odd bug (that will get fixed quickly if you identify it) I can’t point to a better integrated renderer. It’s in fact one of the main reasons I prefer it. No faffing about with weird problems or licensing nightmares. Fire it up, dial a few parms and render.

Fx_enjoyer

tomtm
Will Karma be fully integrated like Arnold in Maya or Cycles in Blender.
At now, it's very user unfriendly.

Which renderer is better integrated? Karma works with every version of Houdini, there’s no weird version lock, nothing to install and license separately. There’s pretty complete documentation on every feature and it works with the rest of Houdini. Apart from a few missing features and the odd bug (that will get fixed quickly if you identify it) I can’t point to a better integrated renderer. It’s in fact one of the main reasons I prefer it. No faffing about with weird problems or licensing nightmares. Fire it up, dial a few parms and render.

Maybe it‘s really well integrated and I don‘t understand the unique concept of USD.

Example A: I build my scene in the obj context. I add a Karma node in the out-context start this separate Karma viewport and Houdini translates all (or most) from the obj-context to USD and I can render it only in this separate viewport.

Example B: I build a USD Graph in the stage-context and can render it in the main Houdini viewport selecting Karma.

Example C: I create a LOP network in the obj context and
build in there the USD graph and can render in the Houdini viewport selecting Karma.

This is very confusing, what is the best way with the best performance?
At least it would be cool, if for Example A the Karma viewport would be accesible from the main Houdini viewport, it‘s very strange integration with a separate viewport panel.


It‘s just confusing if you come from a „normal“ 3D application like Maya, Modo, Blender… :-)

tomtm
Maybe it‘s really well integrated and I don‘t understand the unique concept of USD.

The old Concept for rendering a scene was like this:
3D Scene Setup -> Render Engine Converte Scene in Native Format -> Render Engine Rendering -> Image File

Mantra has ifd files that it understand how rendering a scene.
Renderman version used rib
Redshift uses rs
Octane uses ocs or obrx
in other words every render Engine has it's own Scene Description File Format.

With USD it looks like this when the Render Engine is USD Based:
3D Scene Setup -> USD Files -> Render Engine Rendering -> Image File

Karma uses USD for Rendering the Scene Native
Renderman XPU also uses USD Native
Other Render Engines uses Converters or are in the process to make it Native.

When there is one Format every 3D Tool can understand the Scene (Import / Export) and every Render Engine can render the Scene.
There is also MaterialX that should be the native Shader Format that should bring more portability.
USD as it says is the Universal Scene Description File Format

tomtm
This is very confusing, what is the best way with the best performance?
At least it would be cool, if for Example A the Karma viewport would be accesible from the main Houdini viewport, it‘s very strange integration with a separate viewport panel.

It could be that there is a update or a change, what we know is that there will be a new Viewport based on Vulcan. it could be that the new Viewport will support all Contexts (sop, lop, cop, mat). (just a guess)
The main reason i would say was development Integration as with Solaris there was also Hydra for the viewport and when you want to mix it with other viewport OpenGL it is surly in the background not a simple task. When you know that you need to develop anyway a new Viewport you invest more time in to the new code.

tomtm
It‘s just confusing if you come from a „normal“ 3D application like Maya, Modo, Blender… :-)

Haha! So Blender is considered as normal? IMHO neither Blender, nor for example ZBrush, have normal UI:s. Houdini is neither normal. However, they are still popular.

Going from normal UI:s to something different can be a pain if you are in a hurry. I remember starting with ZBrush as well as Houdini, yeah it was humbling at first. However, if you just give it enough time, and learn the basics first, you should be able to enjoy it.

One example. Once I started learning to make plugins and UI:s for Blender this was really hard and totally confusing. Still it seems quite limiting, however I’ve not followed the latest dev.

With Houdini you can make your node UI with drag-and-drop. You just need basic skills with Python to use it. People complaining too much about Houdini without such experience. Anyway, keep complaining and see you later.

mandrake0

tomtm
Maybe it‘s really well integrated and I don‘t understand the unique concept of USD.

The old Concept for rendering a scene was like this:
3D Scene Setup -> Render Engine Converte Scene in Native Format -> Render Engine Rendering -> Image File

Mantra has ifd files that it understand how rendering a scene.
Renderman version used rib
Redshift uses rs
Octane uses ocs or obrx
in other words every render Engine has it's own Scene Description File Format.

With USD it looks like this when the Render Engine is USD Based:
3D Scene Setup -> USD Files -> Render Engine Rendering -> Image File

Karma uses USD for Rendering the Scene Native
Renderman XPU also uses USD Native
Other Render Engines uses Converters or are in the process to make it Native.

When there is one Format every 3D Tool can understand the Scene (Import / Export) and every Render Engine can render the Scene.
There is also MaterialX that should be the native Shader Format that should bring more portability.
USD as it says is the Universal Scene Description File Format

tomtm
This is very confusing, what is the best way with the best performance?
At least it would be cool, if for Example A the Karma viewport would be accesible from the main Houdini viewport, it‘s very strange integration with a separate viewport panel.

It could be that there is a update or a change, what we know is that there will be a new Viewport based on Vulcan. it could be that the new Viewport will support all Contexts (sop, lop, cop, mat). (just a guess)
The main reason i would say was development Integration as with Solaris there was also Hydra for the viewport and when you want to mix it with other viewport OpenGL it is surly in the background not a simple task. When you know that you need to develop anyway a new Viewport you invest more time in to the new code.

Thanks for explaining.
Hope we will see some improvelents in H20, I just want to layout/shade and light things and render 😂

SWest

tomtm
It‘s just confusing if you come from a „normal“ 3D application like Maya, Modo, Blender… :-)

Haha! So Blender is considered as normal? IMHO neither Blender, nor for example ZBrush, have normal UI:s. Houdini is neither normal. However, they are still popular.

Going from normal UI:s to something different can be a pain if you are in a hurry. I remember starting with ZBrush as well as Houdini, yeah it was humbling at first. However, if you just give it enough time, and learn the basics first, you should be able to enjoy it.

One example. Once I started learning to make plugins and UI:s for Blender this was really hard and totally confusing. Still it seems quite limiting, however I’ve not followed the latest dev.

With Houdini you can make your node UI with drag-and-drop. You just need basic skills with Python to use it. People complaining too much about Houdini without such experience. Anyway, keep complaining and see you later.

I‘m just spoiled because I loved to work in Clarisse for look dev, and Clarisse had the best concepts to layout and render and the power of handling nearly limitless instances and polycounts were just the best in industry.

Would ne nice, Houdini could adapt this, maybe USD is doing that, but instancing is sooo slow if you change things.

Just another question, I found rendering out images with Karma ROP is much slower than how it renders
in the viewport. Did you also experienced this?

SWest
With Houdini you can make your node UI with drag-and-drop. You just need basic skills with Python to use it. People complaining too much about Houdini without such experience. Anyway, keep complaining and see you later.

So how do you rearrange tabs/windows on the fly, dock and undock windows and generally have less static ui?

Not to mention that the scene navigation is not a primary "tool" in the viewport, and that Houdini generally has no idea of monitor geometry and dialogs popup under cursor, highly unreliable viewport, unresolved camera workflows (yes you can build something convoluted and call it better...), unreliable undo, terrible viewport gizmos, "hud" although useful it’s mostly in the way (yes you can turn it off, etc, not the point, it’s not well designed), viewport mask that screams at you (red) every time you lock the camera (although I solved that one), unreliable save and scene crash recovery (solved that one too to some extent), unreliable group selections if switching modes, terrible manual selection "tools", poorly organized display options (sidebar) and and main display dialog, horrendous operation toolbar in most cases, especially icons that look like splotches coupled with sideways click scrolling, under utilized drag and drop, shelf that could be more useful instead of just taking up real-estate (yes many ways to get rid of it non of them elegant and mostly hacky), inelegant bezier drawing tools (maybe with few more iterations it’ll catch up to industry curve drawing standards), disjoined contexts (sort of, although that one requires an in-depth explanation), parameter panel (too many things wrong with it visually from ui and ux pov), poorly named operators and options (hence the high learning curve) and all of this leads to the overall poor ux. All of it is just not very well blended together.

Can you work with it? Absolutely, since most of this falls under the category of QoL annoyances, and I only mentioned the more prominent ones. Other than that there’s nothing wrong with Houdini, it’s more than feature rich and up to any task.