I was making a mirror of this complex model. Multiplication of x*-1 in one axis. And I notice that the mirror tool is pretty fast to create an instance as a user interface and show it up as if it is all in cash. I can rotate it and place it where I want with no problem. The problem arrives when applying that transformation. It takes like a minute or several minutes. (i5 9600K ram32Gb 1080Ti) Applying It looks like several orders of magnitude slower. I understand that there is a lot under the hood. And Rhino was alway having this behavior. But it looks like not optimized. Also copy and past suffers from this behavior. probably scale too (*10). I can imagine that at some point, Iām unable to work because of applying some transformation take too much time and I give up.
And after that, I wait like a minute till the mirror was done.
Iām pretty sure (or at least it feels like) that can be optimized by allocating in memory and applying only the transformation of what is needed. Probably you are working on that. Also, consider multithreading using 128 cores to come. Allow the user to go on over the draft model while Rhino uses all the other cores to make the transformations to the final model so that it does not freeze.
āContent creationā as the kids call it these days just isnāt inherently multithread-able, outside of very specific parts of very specific operations that can easily be split into independent units. Youāre mostly doing this thing then that thing then the other thing, 9 women canāt make a baby in 1 month. Thereās basically zero chance of ever seeing massive general speedups for any kind of āproductivityā application from parallelization, only being able to have more stuff going on at once.
FYI, copying and pasting the same thing as exporting and importing a file, thatās literally what itās doing.
Your Rhino model is at the core a kind of database, and itās not possible(Iām sure thereās an asterisk there but what Google does with thousands of distributed servers isnāt really applicable to this) to let more than one āthingā happen to it at a time while making sure it wonāt blow up and implementing Undo. The quick preview you see for something like that Mirror is only working on a fraction of the data that has to be copied make a new object, and itāll be forgotten the moment you hit Enter.
Hi Jim, Nice car airplane. I was doing something very similar (tailless) at school 90s. Then at Pininfarina, we try to sell it but thinking better in that idea of having an airplane on the road, we give up. An airplane is better to keep it intact in a safe environment. Not vulnerable to a hostile environment as it is the street. Safety first. Still, the evolution of the materials will say.
Thanks for the answer. I appreciate this deeper inside code.
Yes, there will be more amounts of cashe levels IPC and Hz, but Mooreās law no longer holds. ALMA tells me different. That progress is unstoppable. The evolution for CPU from now on will be only more cores (thousands) for each microchip and more chips clusters inside one single main CPU. Can also grow vertically. So Rhino must implement multi-core, as well as games, are starting to do so. Iām a certified C# game developer (with a little of experience) making a multi-core game. If not, cores will seat there doing just nothing. And Rhino in 2020 will be using about 5 or 1 percent of the full capacity of an advance CPU.In other words a mirror will always takes mints unless programmers change the code data layout.
This kind of exporting and importing for a task takes too much time for each function. Iām using a M.2 PCIe SSD capable of 3Gb sec. And the file is just 43Mb. So is not there the problem. What does this import-export mean? that is moving a lot of data from ram to CPU? Where is the bottleneck?
Also, I notice that Rhino is not using 100% of that single core. It is moving all data containing all the undo history to that single CPU core?
The quick preview can be extended in time and not delete after pressing enter. So if I hit Undo, or orbit around my model to inspect it and later I hit undo, (we can inspect it after applying the function) and Rhino in a second core is making the operation or canceling that. This quick preview must be the way of working and inspecting (not forgotten after we hit enter) and Rhino on other tread is making all the operations one after another. At some point, when it catches up, replace it with the new object. We pass a lot of time inspecting the object. Because is frustrating that I canāt inspect the object when I hit enter. And I know that after a minute waiting for the result (that will be exactly the same as the forgotten object!) I will press undo because often the user make the same things several times.
It looks like it is manipulating too much data for just simple arithmetic operations on vectors.
Probably a better option can be just to extract what is needed to manipulate, put it in order and execute the calculations only on that using better the stack and the heap. And not on the entire data ( data-oriented code design) .
Rhino is not a āmulti-threadedā application. Well, it does split off a few minor processes to other cores but nothing major. Thatās because modeling is a serial process. Modeling has to be done āin order.ā
Letās use the example of a box with filleted edges in a shaded display. The render mesh needed for the shaded display canāt be generated until after the edges of the box are filleted, and the fillets themselves canāt be made until after the box is created. First the box is made, then the edges are filleted, then the render mesh created. You canāt put the box creation in one thread, the filleting in a second, and the mesh generation in a third and run all three processes at the same time. They have to be done one at a time, in the right order.
Some tasks in computer work can be multi-threaded. Rendering is a good example. Since an array of pixels are being generated into an image, the image can be broken into 4 quadrants, and each processor can work on one quadrant independently.
With this all said, we are and will continue to look for areas where we can increase performance by threading a calculation or an operation.
Thanks,
ā Dale
But it does not convince me. I can understand that modeling. But If you make a mirror of a mesh you just need few ms to multiply by -1 the mesh points in one axis. The same applies to move the polysurface object. You do not need to rebuild the entire object from scratch each time to maintain a nondestructive way. And if you need to do so you can do it in the background on a second core and laying out the data to use 100% of that core.
In other words, I wish Rhino does not forget that object at the moment you hit Enter and eventually let you continue working.
Of course thatās not necessarily what it does, you donāt know if it uses that or not. What youāre missing is that applying a transform to a mesh is NOT updating the model database, itās a minuscule fraction of that work.
The oft-requested dream of having tasks churn away in the backgound while you do something else isnāt likely to happen because how is Rhino supposed to stop the database from breaking if you change something elseāremember Rhino has a plugin architecture that lets people do anything they want at any timeāand how much the added overhead would be vs just letting the task finish or finding other ways to optimize.
Working with a preview can be very handy. I understand the difficulty but not the problem. I think is possible. A preview, working with a fraction of that work can be handy.
For example, if you copy and paste a mesh, with few 8000 triangular polygons it takes 10 seconds (i5 9600K 4,8Gz). And this mesh is just imported fresh and new. If I take out the material, takes around 8 seconds to copy 8k poly. This instance copy must take only like 10 milliseconds in the interface (or in GPU). So the user can move the instance, visualize it in the final position, meanwhile you can orbit around, think, make a new decision, at that point probably the 8sec copy will be done. And press new functions script. If the copy (in the background) did not finish thinking or updating the instance, it will freeze until finish coping and later will start the new action.
Just making a mirror is pretty obvious about this problem and solution.
Iām starting to think that mys slow down could be a bug related with normal map textures or material problem. If I save small taking out everything the mesh is not the problem and Rhino is pretty fast.
3DM files
V1 past and copy slow (includes a normal map texture)
V2 past and copy fast (does not include a normal map texture)
ok, some strange things: when I do that, no matter how many I copy (1 or many), it takes about 4 seconds to paste. If however I make a copy with gumball, the copy/paste (move with copy) is always instant
Copy (CopyToClipboard) also takes along all the materials in the document. If there are textures, those are embedded with that copy. Huge textures make that extra slow.
Note that 1k -> 8k is an increase of 64 times the dataā¦
There are some bugs in our tracker related to this copy&paste problem. Iāve nudged them a little.
@nathanletwory both seem to make no sense to me. Why is it needed to copy all materials instead of just the material(s) of the object? And copying the textures seems completely unnecessary as these are always referenced.
Also whatās odd is that copying doesnāt take much time, itās the paste that is becoming very slow.
@Gijs - it seems to me that the copy and paste terms are used somewhat interchangeablyā¦
The RH-47093 issue was marked āRelated toā RH-25208 (āPaste Takes Foreverā) that is visible to developers only:
