Multiple Rhino 6 problems - Make2d - Display of textures - command line

[hny]

We have now switched the whole office over on Rhino 6, and unfortunately we are now bleeding many hours on small silly issues, so hopefully we can come up with some solutions and workarounds quickly.

Pure Rhino issues:

1. Make2D is omitting many lines from even the simplest models as soon as we are slightly away from origin.
   
   
   i recognize that a million units may seem like a lot to some, but for us as architects, it quickly comes to it on anything larger than a single house.
2. The Command line does not seem to “learn” as it did earlier. When using the same command often, Rhino would adapt to it, making offsetSrf being preferred in some sessions, and offset preferred in others. Is this omitted intentionally?

Rhino/v-ray combo issues:
I will share the following issues with ChaosGroup, since the issues can be on both sides of the table.

1. Materials with opacity-maps does not display correct. They just appear solid.
2. Many materials does not show their diffuse-material. This seem to apply to some materials created in v-ray 2/Rhino 5 - However it has cribbled our transition a lot. - I would like to figure out which material-compositions is failing, but my model has been frozen for an hour now, which brings me to:
3. Old models, made ind Rhino 5/vray2 is very slow in Rhino 6. not only do their render slow, but previews is impossible to work with. I am reading a constant high load on the network. Do Rhino 6 handle bitmaps differently? Like it constantly try to get the textures, instead of saving them in the RAM. And when i say slow, i mean really slow. Before (Rhino 5) i could work in a simple rendered view (without scene lighting, thats a killer) or in a shaded view with textures show - That viewport mode became more or less the office standard. But now, it brings the computer to a crawl. Which is scary, since i have the newest and fastest machine in the company.
4. A smaller bug with a workaround: It seems that when we type “Render” in the command line, the work-file is locked until the render is stopped again. But if we press the render button, we can continue to work in the model while rendering.

I will try to have this thread open during my workday, so i can help you the best possible way to find some fixes.

[pascal (Pascal Golay)]

The Command line does not seem to “learn” as it did earlier. When using the same command often, Rhino would adapt to it, making offsetSrf being preferred in some sessions, and offset preferred in others. Is this omitted intentionally?

Hello - that seems to be working here - is Autocomplete and ‘Fuzzy autocomplete’ enabled in Options?

-Pascal

[wim (Wim Dekeyser)]

@hny

Make2D is omitting many lines from even the simplest models as soon as we are slightly away from origin.

You didn’t include a model - are you finding that Rhino 5 did a better job on the same file?
As for far away from the origin:

Make2D not working properly - Rhino 6 Windows

Thanks for posting the file. This is a great example that hits all the weaknesses of Make2d. Units The combination of Model Tolerance, units, size and location. First how its supposed to work. Tolerance is the desired accuracy of the result. I use model where it is in the coordinates its stored in. I use double precision computer arithmetic that has about 16 accurate digits. Since this model has coordinates with 7 digits before the decimal point and a tolerance = .0001 of 4 digits af…

[hny]

Hi Pascal,

I will check with the guys who mentioned this issue. I have not encountered it myself, but i also use alias’ for almost everything else.

[hny]

Hi Wim,

I did not include a model since it is an issue which is so easy to replicate. After many of my colleagues mentioned repetitive issues with Make 2d after the switch, i simply drew some boxes, moved them a kilometer away from origin, and the issue was there. I have not side-by-side tested a file in rhino 5 to compare, since our Rhino 5 license is out now we run Rhino 6. But i can see in the thread you send through that others have proved the issues was not there the same way in Rhino 5.

The whole far away from origin is an issue i can understand from a programming point, where you probably have to limit the digits in use. But the real solution should not be “move it closer to origin”, but more a matter of moving origin to the model when doing the calculation. When making massing-studies for buildings or other large developments, we often end up with areas far away from origin, simply because they are next to each other. We breifly discussed internally if this means we have to move to meters, but i am a bit sad to give other software users a reason to mock Rhino in the architecture world. Architecture is in mm. That is the standard we are all taught in school. That is what all entrepreneurs and workmen read from drawings. Is there a legacy mode in Rhino 6 we can use in cases where make 2d fails?Make2d-issue-file.3dm (311.2 KB)

[wim (Wim Dekeyser)]

Hej,
Thanks for that file!
The incorrect classification of lines as hidden is a known issue - RH-46732
@GregArden has that one high on his list. There is no legacy code in RH6 so I recommend always generating hidden lines as well. For the time being, it will be a manual job to place those on the correct layer.

[hny]

Thats good to hear. So its the classification which causes the issues.

Regarding the many v-ray integration issues, with wrongly displayed materials, is that something you guys have any influence on? Like Rhino not reading the opacity of materials in v-ray?

[hny]

The guy who reported the tendency did have fuzzy autocomplete on. I will ask him to be more aware of the specific issue, so i can report better to you guys. Only difference he has, is that he is still running Win7, but i doubt that has anything to do with it.