Hi,
The first 3 materials, I didn’t make.
It would be a time-consuming thing, but for V8, I would be willing to lose backward material compatibility, and go with PBRs only, for reliability. Then there would be one UI for it.
Although, I have no idea how to do Fresnel Reflectivity in PBRs.
A person with one watch will always know what time it is. A person with two watches will always be unsure.
–Mark Twain, others.
@Brenda do you have a way to repeat this issue? I don’t recall every having seen this at my end.
Hi,
(Sorry about the late reply. My health has been interesting. LOL! )
When I push Rhino with large textures, bad things happen. To recreate the bug, you have to offer it a challenge, such as a drawing with some 2048s, and perhaps a 4096, which a FPS video game can easily digest. I don’t think they make FPS games with anything smaller than 1024s for walls.
Some time ago, I had submitted my diner project to McNeel, so they would have something to play with. It might still be around.
Currently, to use Rhino with large textures, you need care and patients. I am not finding the Serengeti version much better, yet. Oddly, if the texture performance issues were sorted out, Rhino could be the defacto go-to video game editor, and new industry standard. I had read that Rhino was used in the new Blade Runner movie, although, it is a powerful design/CAD program.
I use large textures all the time, so that still gives me no clue how to reproduce this.
@andy do you have an idea why Rhino would create materials that start with rdk$?
Thank you for the reply.
Just so we are on the same page, what I meant by large, was 4096 pixels square, which is sometimes helpful for hiding repeats on a ground materials, which are close to the virtual camera, yet head off into the distance. A medium-large would be 2048 pixels square.
I am using blocks. Perhaps that’s not speeding things up much? : )
AFAIK, this bug was fixed. Perhaps there was a regression?
Too late for RH8 but I hope this will be done for RH9. Especially the UI/UX is terrible the way it is right now. Setting up materials involves different panels that are all very confusing and each have sub menues. Imho, all those material related panels and menus need to be ditched completely and instead move all material related stuff into a node based system.
I really hope this gets done in RH9.
It still is around.
For Rhino 7 and later you should change the Cycles Emissive material to Physically Based material and set the texture to the slot you want. You have a lot of very high-energy emission materials, in Rhino 8 that definitely blows everything out.
I need more time to understand the scene and setup, but here with about all of the emissive materials turned down to lower values. Main thing I want to show is the charger screens on the left - replaced with regular PBR material, emission texture in the emission channel, and strength just 1.0 - the 1000 or so you had made it look completely white.
anyway, this needs tweaking to make sense.
For many of them, I did. Still, I wish we had some real-world or science-based lighting units. It’s still very difficult to have small bright lights.
Large textures slow Rhino immensely, not just for rendering or real-time rendering.
Raytraced/Rhino Render loads large textures now really fast in Rhino 8, since it uses now OpenImageIO directly for that. Any other slow-downs are probably from the GU in relation to those textures.
Respectfully, I hope the Serengeti version you tried was faster than the one I did.
Rhino 8 Beta is indeed faster than Rhino 7.
