I’m your project manager now. Welcome to your next 2-week Sprint.
Just wanted to share a sense of what we see as priorities to have a high-quality, shareable (among internal teams) and useable materials’s library. Including PBR for viewport use.
One early problem we had was object mapping, and Nathan helped us solve that, we had no idea Rhino could already do this. We might also need Triplanar mapping w/ blending, but we’ll hold off to that request until we see how far we can get with everything else. So let’s move on to our priority list:
Fixing Viewport performance with large textures. Maybe there’s a texture quality setting, like render mesh setting so we can work in lower qualities and take high rez viewcaptures in higher quality? cc. @jeff
Fixing material editor performace. We can provide example files where we really struggle seeing material balls updated and changing textures is super slow. But you can easily do this by assigning a handful of 4K and 8 K textures. Even as few as 3 materials with PBR textures are making Rhino V7 melt.
Have a way to do color overrides to materials. So we can maintain material libraries centralized and in-sync by having an RGB color override for different parts of a model. Keyshot can do this very easily. You just drag-n-drop an RGB color into a material and it changes that material’s color.
Support for multi-material per object (not to be confused with per-face material) so we can have objects with certain materials assigned for viewport, and different materials assigned per render engine. We do not see good rendering engines like Octane and Vray getting any more integrated into Rhino anytime soon. We also don’t see any other rendering engine getting good/fast anytime soon. So we need to be realistic and work around this by having material assignments to object that are different based on what rendering engine (or viewport) we are using.
I think these needs we are asking for are not esoteric, nor niche. These are foundational things that any of your customers will be facing once they start working with material libraries that are high quality, and centralized. Even the one that Kyle is exploring into building.
Please let me know when you can start, and when can we expect to see progress on these.
Any user questions just ask, of course. Any resourcing questions just ask @brian or @bobmcneel. They’ll give you whatever you need, I’m sure.
One of the jobs of the project manager is to log reproducible bugs in YouTrack with detailed information about each request. This involves:
A description of the steps required to see the problem (including opening files, running commands, etc)
A clear description of what isn’t working.
A description of what should be happening instead - screen shots, doctored images of UI, etc are often helpful here. If needed, do all the hard steps to get the answer you want, and include that.
Separating concerns as much as possible - making one giant bug with lots of sub tasks generally won’t get any action, because those bugs require everything to be solved in order to close it.
I encourage you to put all the examples you’ve talked about in separate YouTrack issues so they can be evaluated, prioritized, and (if appropriate) worked on by the developers.
Since I can’t really compete with free project management, I’ll get out of the way now and let you proceed.
There is a way of tinting textures already built into Rhino 7 - attached is a simple concrete material in a 3dm file which has a multiply texture in the base color slot.
You can change the tint color fairly easily to do this. Obviously, for this to work, you need to start with a fairly neutral color for the base color.
Fixing Viewport performance with large textures. Maybe there’s a texture quality setting, like render mesh setting so we can work in lower qualities and take high rez viewcaptures in higher quality? cc. @jeff
I have been testing with 8k textures all day, and the display performed fine. If you have a model that repeats the issue, please send it along.
I don’t want to interupt @gustojunk but i think the case of multi material is named wrong here. Though it actually could work to hold at once many engines materials… In my opinion the problem lays in material wrapper and no ecosystem around it. Thats why every engine has own UI on top of Rhino instead of being integrated like in 3ds max. Simple example of this is material breaked on Material and RenderMaterial where those two besides name have nothing in common while they should be based on the same abstract class which would wrap all possible materials and would be elastic to implement own slots for each engine but would handle the base properties for display purposes. If this sounds interesting let me know ill elaborate further.
RenderMaterial is the material that we use that every engine could customize from. Material is the old-school 1982 OpenGL material spec that was in Rhino 1.0.
If you want to to do a renderer integration into Rhino and provide your own custom material types, you have everything you need to do so.
Hmm… That’s interesting didn’t know so shouldn’t be Material obsolete at least - besides it still takes significant role in IO part while RenderMaterials are not present. Bare in mind that I’m fluid only with RhCommon not with native side so i can be wrong.
Thats for sure and without doubt I just see inconsistency on the RhCommon side in the middle of Render and Document space.
If my suspicions isn’t right well there had to be a reason why engines never integrated to rhino like in case of max - certainly it could be caused of totally different reason.
The reasons for the two are historical and there’s really no need to dwell on it. I have wanted to get rid of the old stuff for years, but the change would be too much to bear for users of the SDK.
We basically use Material in the display, and RenderMaterial for full render engine implementations. As I said, there is plenty of scope for developers to write custom materials for their own engines.
Different materials for the current renderer and the display would be hard because of a decision we made about 3rd party renderers.
If you have a custom material (and in Gustavo’s) case, I assume it is Octane, then Octane gets to decide what ends up on the display for that material. If they make a poor decision, there’s little we can do about that.
Thanks so much for jumping into this work. Today’s summary:
fixed. thx!
@IgorK will test later today or tomorrow and provide feedback. We also suspect that teh slow down could be a rhino-wide slowdown base on Material browser. But we’ll confirm.
This is a complex subject. I need to think more about how as a user/customer so we can reconcile your approach and vision with the realities of what 3rd party developers are doing and have expressed that they will not do. I’ll get back to you soon.
Hey Gustavo, if I can jump in here on #5, it seems there are maybe two main objectives lumped together:
allowing to have materials set up for multiple engines simultaneously, e.g. for every job you have some toon stuff you do with engine A and beauty stuff you do with engine B, and you’d like to be able to set up materials for both cases in one model (i.e. as opposed to saving out copies for each, or using version control, or somesuch).
for whatever reason, you’d like to render with engine A, while having viewport (on a per-object basis), handled by engine B.
Am I reading you correctly? Just asking because the former seems more fundamentally important (and is a request I’ve heard quite a few times before, wrt a few different 3D platforms), and seems like something that could possibly be handled by a plugin (not one that currently exists, afaik). The latter seems more difficult.
1: Generally, performance in “Rendered” mode is OK, but start to degrade with more objects/materials. We tested with Rhino materials and then with PBR materials. PBR materials show some slower FPS in the Rendered viewport. To solve this issue we might need something like Draft/Quality mode, where we use Draft mode when modeling/editing models and then switch to Quality mode when we need to make screenshots/renders for a client. Or this could be automated feature when while we editing/interacting with viewport/model - its draft mode, but once we don’t interact with model/viewport - it shows Quality mode. Does this makes sense?
2. What’s bugging us more is performance when interacting with Material editor. Specifically, when loading/editing texture slots. For example, if we have a 4K/8K texture assigned in Color slot and we want to go back and change mapping scale - it could take a 2-15 seconds for it to open, then another 5-10 seconds to apply changes to mapping for example. We testing 4K/8K textures. More textures results in slower performance.
The original problem we are trying to solve:
Is a combination of both JD1 & JD2. (I’m calling thee JDX to differentiate form my original requests numbers).
JD1: Yes, we want this. We want to have a way to give each object a Rhino viewport material + an Octane material + maybe a Vray Material (less often these days) + maybe a Bella material?
The fundamental problem is that our preferred, easiest, fastest and most consistent (because we also use it in Modo) render engine is Octane. And we can’t even see the RGB value of our octane materials in the Rhino viewport. So we want to have also separate assignment for Rhino viewport.
JD2: At the same time that we are seeing something on a floating frame buffer in Octane with Octane materials we also want to see in in the Rhino Rendered Viewport with Rhino materials. Not ‘per object’ like you describe, but globally.
The new opportunity this presents:
If we have like a material table of some sort, we can assign different materials for different criteria, not just render engine of choice. Something like this:
For example we could use libraries for visual management of how are we building these models (we do a lot of prototyping): CNC? Formlabs? FDM? What material? in-house? Outsourced?
We could also have materials to show if a model has unwrapped meshes yet of not? Very important for our AR work.
I’m confused as to why JD1 and JD2 and very different? COuldn’t a render engine we just another viewmode? Just like Rantrace (Cycles) is doing, and if I recall correctly Maxwell had a version of this too, where you could set a viewport to show you Maxwell progressive rendering.
