Brenda
Can I have the models? You can send them confidentially to andy@mcneel.com
Andy
Hi Andrew le Bihan,
I sent the file. Thank you for looking at it.
It would be interesting to ask some Rhino users to donate other larger projects, for experimentation–in the same way that things that were problematic to fillet were asked for.
Brenda
Some early results:
- The slowness is caused by the number of lights. Rhino really doesn’t like a lot of lights in OpenGL views because of the need to create shadow maps for each light. I believe that there was a potential fix for this in the pipeline, but it isn’t any better in V7 at the moment. @jeff will have to pipe up on this one.
There is a workaround though - you could turn “Use advanced GPU lighting” and turn shadows off for your rendered and raytraced views.
Once I do this, the model is very responsive.
- The brick tiling issue - I can see that there might be an issue here, but at the moment I can’t figure out what it could be. Basically the problem is caused by the UVW repeat values in your cylindrical mapping. If you set them all to 1.0 it is fine. I have never liked exposing UVW repeat in the object based texture mapping settings…
I’m unable to repeat the issue where it is different in Rendered and Raytraced modes.
The part of the brick wall that shows extreme stretching has a U repeat of 0.2 - which doesn’t exactly what it says on the tin. It stretches it 5x.
- Andy
Hi Andew Le Bihan,
If I may ask, what are the specs of your machine?
In rendered view, there are less than 2 dozen lights because most of the lighting is provided by Cycles, and is not supported by OpenGl views. This lighting was used for spotlights, where Cycles-Fall-off might not have been realistic.
I generally use a mixture of views. Shadows aren’t necessary for texture alignment, but correct mapping is. If you change to Raytraced you will see the correct brick mappings on the right side of the diner.
A person with one watch will always know what time it is; a person with two watches will never be sure.
I could be said, that while I love modeling in Rhino, I hate applying materials. With materials locked both edges of an object–every time it’s resized, it needs to be remapped. Ick! We can use world mapping, but then we cannot move the object. What we need are sized materials. We are making scaled objects, which will have scaled materials. As you can see above, I went through great lengths to make the stainless on the side of the diner–mostly the same size, as best as I could.
If someone at McNeel applied textures/shaders/materials using 20-year-old GTK radiant for one single day, Rhino would be the better for it. The current materials mapping options are much too time consuming. A No-Draw/Caulk material would help with both rendering speed, and Z-fighting on close sufaces.
I used to make 5,000 simple textured objects a month.
Thank you for the reply,
Brenda
Brenda
I’m going to concentrate on the performance issues here…
Raytraced display mode uses the rendered view mode as a base. So if rendered view is slow, Raytraced will be too. 24 lights is a lot for Rhino as I stated above. And the workaround I have will solve it.
Please do that and tell me if it solves your problem.
I imagine my specs are much the same as yours - a 1080 and a reasonable i7. This issue isn’t really helped by faster hardware. You will be able to bring Rhino to its knees on any hardware with a fair sized model and a ton of lights.
Andy
As for the mapping, it sounds to me like WCS mapping with a per object frame would solve your problem. Should I add this to V7?
Andy
Hi Andrew le Bihan,
“As for the mapping, it sounds to me like WCS mapping with a per object frame would solve your problem. Should I add this to V7?”
Yes, please, please, please : )
It sounds like a world-coordinate-system per object would approximate what I want, to:
- Load a texture(s) in a material
- Give then a pixel/world-unit scale
- Apply the material to an object
- If the object needs to resized, the mapping/material doesn’t have to be resized, but sometimes might have to u/v offset corrected to the edges of the object.
What you end up with: you can siding, roofing, grass, paneling, marble on you object, and resize it often in the case with seamless textures–no adjustments would be necessary.
As an ex-Max person, and one who has some experience with Maya, most people from the single-object modeling paradigm–won’t miss and won’t know what they are missing if they never had it. Material application is something you do between modeling and sips of coffee–instead of so much a long ritual.
There were early challenges, such as cutting/pasting, and also object rotation, but it has been done.
In the old days, I think that someone made a tool that randomized the U/V coordinates, for such things as stairs, which if just copied is quite noticeable.
~
I have noticed that Cycles first draws a quick preview in Rendered/OpenGL, but perhaps those settings could be further lessened for increased workloads, perhaps though a setting.
I am using sneek-peek surface lights in much of the exterior. I will experiment further with their falloff, so that the redundant spotlights might be minimized/eliminated. Though, for small but bright lights–Cycles t is unlikely to offer enough brightness–while not having the visible material blown out.
In your spare time : ) Make the diner’s interior lights bright–yet still let the globes have any perceivable saturation.
Still, I am of the opinion that the number of point/spot lights is reasonable; the amount of glass and chrome in the diner is unreasonable.
~
A system-wide Caulk/No-Draw material helps bring free rendering performance. It can be applied to the bottoms of object set on floors, the backs of mouldings and picture frames on walls, the tops bottom of balusters, top and bottom of every stud in a house, the edges of window glass–and the renderer doesn’t have to draw them. Perhaps even, those surfaces could be excluded from meshing in the first place. To the renderer, the effect is like exploding an object and deleting the non-visible surfaces–but without the mess offered to what ever reprocessing scheme you have for rendering, because you still have valid closed polysurfaces.
This is one reason why I asked for per-surface materials for V6. : )
Brenda
The “Caulk/No draw” - I really can’t see what advantage it brings. You mean that you can model the way you want (with closed polys), but not include it in the meshing so the model is lighter?
Seriously - with this size model, the issue has nothing to do with mesh faces. It’s the lights - and I know you don’t believe me because you think that 24 lights is nothing - but I’m telling you it’s the lights.
- Andy
Yes - but it’s not just when Cycles isn’t producing the frame fast enough - it happens for every draw. There are reasons for this that I won’t go into, but basically, Raytraced will always take the amount of time it takes to draw a Rendered view frame as a minimum. You can change this by modifying the display mode settings for Raytraced of course - and maybe we should change the defaults here.
1 Like
I am sorry about the lights.
[It make me wonder if some strange per-pixel lighting with shadows could be done, ala Doom 3 2004, though that would make soft shadows difficult, but it has been done. I never played with the ID4 engine, but it appears to use light/shadow volumes instead of maps.
https://www.katsbits.com/tutorials/idtech/dynamic-lighting-principles.php
Oddly, I used to study this stuff.
Oddly, the Dark Mod implemented soft shadows from this technique. Their puddle shader ain’t foolin’ anyone. : )
]
Happy New Year’s.
There may indeed be issues with lights, but the ability to leave a few triangles off, so we can put extra ones in elsewhere is a nice feature. It might let us toss a few more chairs in the room–without exploding the block and deleting the bottoms of the feet.
Someone else had mentioned that I should extract all the meshes for the diner, and to use those, but that makes things such as changes and bugfixes a nightmare, as well as taking a lot of fun out of using Rhino–because it becomes too much about the workflow/process and–what was I working on? : )
Even the diner scene has custom rendering meshes to lower triangle counts–especially in the curved trim. The neon sign is very coarse. The outside soffit metal with the ray bent design is almost co-planer with what’s next to it.
Having a no-draw materials would also let us put thin sheet flooring over a concrete slab, without worrying if it will render.
A show all meshes/triangles/quads command would be nice tool because I didn’t notice how many triangles Rhino put in the trim, until I started checking object to object.
Brenda
All of this is speculation - Rhino should be able to handle a huge number of triangles. The best way for us to deal with high-poly scenes is generally to find out where the bottlenecks are and speed them up - it’s very rarely just a case of face count.
Lights…different matter.
- Andy
I think @jeff has got some good ideas about how this could be sped up. I will leave that discussion to him.
Respectfully, Nodraw materials were tested in dozens of video game, using several engines–where framerate is life itself.
There is no free lunch.
Mesh-wise, the diner scene isn’t that complicated. It’s just a prop. For a friend, I designed a landscaping machine as a prototype and functional test platform, and from my real-life experience, the kind of complexity from triangle count is indeed an issue, like toggling the layer that has the chain, in the image I will send.
Brenda
Sure…there are plenty of things we could do to improve Rhino. The question is which things. If I see a customer having a problem with a real workflow on a very high poly model, I will try to do something. But we have customers that are modelling whole cities, with millions of polys. And it’s fine.
No amount of polygon culling will help if the bottleneck is somewhere else.
Andy
Are you now satisfied with the performance of your diner scene?
Perhaps other means could be used to increase performance, such as a checkbox for a selected surface, that cause the surface not to be drawn, under certain circumstances. The whole material method is only one metaphor, one.
The little diner scene isn’t high polygon. It has a lot of transparencies, and reflections which likely linger out to the bounce extinction setting. It has a few large textures, but it’s a small scene.
You can make and entire city with just some textured boxes, and it looks pretty good. Job well done. But when you draw a machine that has over 1,000 fasteners, many of them will be round washers–not the square kind : ) , and even if they have no threads, every triangle counts.
Elsewhere, someone was using Rhino to lay out a factory floor. People are making stadiums in Rhino, 2 so far, I believe–and there is only so much computer performance to be had.
I cannot and will not speak for other users, but I have been on this forum for enough years to know that rendering performance is a bottleneck to workflow with larger projects, and that’s why I am asking for improvements, please.
A nice relaxing video of hot-room, that would have been pretty high-polygon : )
And it all had to work together. The best part would be if there was a loss of power to the system that cooled the frozen salt seals, causing them to melt–and gush radioactive, barely subcritical salt-fuel mixture all over the place.
I supposes that this had a pretty high triangle count as well, even more than my diner. : )
FWIW, in my experience it’s not the high polygon count that slows rhino down, but rather number of objects. You can try this for yourself. Make a mesh box and make copies of them until your display speed becomes sluggish. Now select these meshes and join them into one and you’ll notice your display speed flies again. This also makes a huge difference in render initialization time.
Yeah, not to mention that extracting render mesh and using that can be a good choice, depending on your workflow.