This topic contains 34 replies, has 5 voices, and was last updated by Eric 3 months, 2 weeks ago.
October 4, 2019 at 1:19 pm #2317
Likely it will be done similar to how it has been done for maya, with ui for a linked layer being shown embedded in the material that links it:
Cinema should lend itself well to our model, since you have long had there the “linking” of one thing to another, with the familiar “back/next” and “up/down” navigation in the attribute editor.October 4, 2019 at 5:29 pm #2318
I would like to see a list of all the components in the stack. Almost every material will end up being multiple stacked and blended layers, Its hard to make a car body material without 13+ layers, if you have waterdrops, wetmud, drymud, dust, dirt, grease, stickers, laquer, numerous decals, sparkle, exposed undercoat, rust… I could go on.
In order to build complex materials we need the cleanest possible UI, not just for speed but also to give the user some headroom to think..
I am worried that the strive for efficient coding through automation and updatability will lead to a less efficient user experience…. Sorry that sounds a bit harsh, it is also based on many assumptions.October 4, 2019 at 5:57 pm #2319
In that case, I think we have some small misunderstanding regarding the meaning of layer as used in bella. A layer in bella is not something for doing decals or such, it is literally a simulation of a thin layer of dielectric over the substrate material.
For the kind of thing you are talking about (I think) we have the blend and stack materials, which do what they sound like. If you want a parallel to something like maxwell, it would be like having an mxm where each layer referred to another mxm file, and you could blend or stack them, mask them, and so forth.
But note, you don’t “embed” materials here, as you would have to with mxm, you just refer to them, and you can therefore refer to one from multiple different blend or stack materials. So you can set up, say, a particular dirt material, refer to it in multiple blend/stack materials, and have all those materials be automatically improved, when you then go back and improve the single dirt material.
So to try and correlate this with your comments above, I infer that your main point/concern is that if you have, say, a stack material that refers to 13 other materials, you are interested in making sure that we have a convenient list UI to show those 13, where it is easy to get an overview, to select individual ones for editing, to manage masking of them, and so forth.October 5, 2019 at 2:23 am #2320
‘you are interested in making sure that we have a convenient list UI to show those 13, where it is easy to get an overview, to select individual ones for editing’
‘so you can set up, say, a particular dirt material, refer to it in multiple blend/stack materials, and have all those materials be automatically improved, when you then go back and improve the single dirt material.’
I think I’d rather update specific materials manually by importing newer material data. But I can see that this may come in handy for some situations.
But overall the philosophy of Bella pretty much contradicts my philosophy around 3D, because 3D for print/animation is quite different from programming. We need efficiency and flexibility, less need for automation and updatability.
If Bella was destined as a game engine the whole referencing concept makes sense, but unbiased rendering for games maybe 50 years away.October 5, 2019 at 3:41 am #2321
It seems you may be getting some impression I’m not intending to give, because referencing something in multiple places is completely optional.October 5, 2019 at 4:58 am #2325
Optional is good.
I am still worrying that your coding philosophy (which promises less entropy) will bleed into the user experience, in a ‘process porn’ kind of way, It’s a kind of trend in 3D software and I haven’t seen any great art coming from it.October 5, 2019 at 6:09 am #2326
Well, that’s partly why I invited you here early, so I can try and check my instincts against yours.
The system is designed flexibly, because while we can always hide or ignore flexibility in a system that has it, we cannot simulate it in a system that does not, and that is fundamentally important when we must interop smoothly with many third-party systems, which all come with their own peculiar take on how to do 3D.
So while programmers may tend to geek out over abstraction or elegance for their own sake, just know that I’ve also been dealing directly with customers in this space for many years, and I have it in mind at all times, that my primary purpose here is to take what would have burned up 8 hours for you, and try and turn that into 6 hours, so you can make tighter deadlines, spend more time with your kids, or what have you.October 5, 2019 at 3:17 pm #2327
Thanks, I do feel reassured. I need to build a material in Bella before I can offer any decent feedback. Right now its all jargon to me (substrates, dielectrics, virtually thin layers). When I have undserstood these concepts I will pester you to give them more sensible names 🙂October 6, 2019 at 5:00 pm #2333
Just a test post, this uploader is offering forever storage and no resize, and its accepting 16bit png. drag-drop
I still have to right click ‘open image in new tab’ to see the original size, maybe that’s preferable for large images.
The quality is still the original file, not sure if the 16bit data was kept, Much better than imgr and easier to use.October 6, 2019 at 5:06 pm #2334
Interesting, thanks for the heads-up, I’ll mention it in the sticky about posting images.October 10, 2019 at 12:06 am #2348
Currently working on adding import capability, initially supporting (not necessarily all versions of) .3ds, .dae, .fbx, .obj, and .stl. Cannot claim that material translation will work this nice in all cases (depends what is in the file, and whether it actually makes sense) but here is an .obj example (I also have .3ds of this model, and it works similarly):
The floor is something I put there, not from the .obj. In the import, we currently retain structure present in the imported file, parented under a top-level xform representing the imported model, and the translated materials are available for editing, no different than any others.November 8, 2019 at 8:39 am #3723
hello Jeremy.. hehe
I played a bit this afternoon (UI version.. as have no maya atm)
I really like it.. did not take too long before I found how to get a render done..
Sure pretty different than Maxwell..
do you have a roadmap sort of..?
viewport, sss, disp…?
Cheers to the Team
HervéNovember 8, 2019 at 9:30 am #3725
Hey Hervé, nice to see you, and I hope you have been doing well. 🙂
We don’t have so much of a definite roadmap right now, as a huge to-do list. But we should, so we’ll make a point of doing that. I do know SSS and disp are very high on our priorities, but a viewport is less so for us than doing more plugins. The rough plan there is to extend the IPR with more functionality — picking objects, outlining objects, setting camera to view selection, and so forth. The idea being that this, plus a GPU implementation of IPR may be enough to avoid the need of an opengl viewport, but we’ll see.
Just curious — you were a lightwave guy, right? What are you using these days?November 8, 2019 at 10:11 am #3729
Hello Hervé! A big pleasure to see you here 🙂
Can’t wait to see the potential of Bella in your hands. Welcome aboard!!November 8, 2019 at 5:04 pm #3731
Hi Herve, good to see you at last.
JD, I think working in IPR is hideously slow, just a gimick, serious work is done in open-gl.. IPR maybe features in youtube ‘tutorials’ as eyecandy only.
I expect Octane IPR workflow soon leads to mental illness, judging by their renders 😉
IPR is great for tuning normal map strength interactively, positioning a light, things like that.
You must be logged in to reply to this topic.