[C++/WIP] Creating render meshes when viewport is not shaded


(Menno Deij - van Rijswijk) #1

I just want to report that I see strange behavior when our custom BRep object is asked to generate render meshes. If no viewport is shaded, we don’t generate these meshes, and exit CreateMeshes with a count of zero.

Now, every time the user changes the camera on a viewport (by e.g. panning, rotating), the DestroyMeshes and CreateMeshes functions are called in quick succession. Nothing much happens, because there are no meshes to destroy and when no viewport is shaded, no meshes to create.

Then, when one viewport becomes shaded, the render mesh is created. After that, the calls to DestroyMehses and CreateMeshes cease.

This behavior is new; Rhino5 does not do this.


Rebuilding Meshes
V6 Goal: Display Performance
V6 Bug: EdgeSoftening updated by moviing object
Camera movement is not fluent in the very begining
(Brian James) #2

@dale can you help here?


(Dale Fugier) #3

Hi Menno,

I will look into this and let you know what I find.

– Dale


(Dale Fugier) #4

@jeff, @stevebaer, any ideas about this?


(Steve Baer) #5

Not really other than there are potentially a lot of other reasons to create render meshes than just for shaded display. I guess we will need to type up a sample and see if we can repeat it to figure out what is calling this function.


(Dale Fugier) #6

@menno, I’m assuming this is in C++. What are the odds of getting a cheap sample that repeat this behavior?

– Dale


(Menno Deij - van Rijswijk) #7

Find attached a plug-in that reproduces the problem.

Steps to reproduce:

  1. compile & load plug-in
  2. create a sphere
  3. run the command RenderMeshOnCustomObject and select the sphere
  4. the sphere will be drawn and its bounding box will be drawn in red
  5. this is important: in the perspective viewport zoom in until the sphere no longer fits inside.
  6. in the command history you will see that after each move, pan, zoom the CreateMeshes and DestroyMeshes functions are called.

ad 5. I have noticed that when sufficiently zoomed out the functions are no longer called.

RenderMeshOnCustomObject.zip (15.5 KB)


(Willem Derks) #8

Hi Menno,

FWIW: might this be related to the auto target setting being active?
I’d test it if I was able to compile your code but that is beyong me

-Willem


(Menno Deij - van Rijswijk) #9

I don’t know, I’ll test it when I’m back at work tomorrow (almost today, I should get some sleep :wink:)

Update: it does not make a difference.


(Dale Fugier) #10

Hi Menno,

I’ve tried your code in both a Release and Debug version of Rhino, and I am unable to reproduce what you’ve reported and what your video demonstrates. So I’m going to need you to do some more investigating.

Are you running other plug-ins that you or someone else has developed? Anything special set in your Wireframe display mode? (Mine is set to the factory defaults).

– Dale


(Menno Deij - van Rijswijk) #11

I’m not running any third party plug-ins & all display modes have been set to factory defaults (*). But I think I have found the culprit: I’m using a 3dConnexion space mouse. When I disable the plug-in that supports this mouse, the problem goes away.

(*) I noticed that the Ghosted display mode does not revert to black text after a reset to factory defaults: the Transparency option stays blue, but on ‘Restore Defaults’ its value does not change.


(Vanessa Steeg) #12

Hi Menno,

I was just dealing with another user that had the same problem. He had another issue, nothing happened when he tried to tick/untick the checkboxes in the Ghosted display mode Options page. Are you seeing this too?

A hint that might be at the origin of this, he had imported his Ghosted INI file from V5 into this WIP.


(Menno Deij - van Rijswijk) #13

(*) I noticed that the Ghosted display mode does not revert to black text after a reset to factory defaults: the Transparency option stays blue, but on ‘Restore Defaults’ its value does not change.

This is not the problem I am describing in this topic, it is just an aside of something else I noticed. The problem reported here is due to the plug-in of the 3dConnexion mouse triggering spurious CreateMeshes and DestroyMeshes in my custom object.


(Dale Fugier) #14

Nice, thanks for reporting this. I have an idea what’s up, but I’ll need to dig up my digitizer. I’ll let you know what I find.

https://mcneel.myjetbrains.com/youtrack/issue/RH-37153

– Dale


(Vanessa Steeg) #15

Nor was I trying to solve your initial problem. I piggybacked on your second comment to see if I could find some consistency for this particular issue and help out other customers.


(Menno Deij - van Rijswijk) #16

No worries, I’ll try to see if this is related next week.


(Menno Deij - van Rijswijk) #17

I was just dealing with another user that had the same problem. He had another issue, nothing happened when he tried to tick/untick the checkboxes in the Ghosted display mode Options page. Are you seeing this too?

Most of the changes I make are immediately updated while the dialog is open. Others (like lighting settings) only update on a draw refresh following a move of the object.


(Dale Fugier) #18

Hi Menno,

I am finally setup to repeat the problem you are seeing. But if I just generate the meshes, when {{CMyCustomObject::CreateMeshes}} is called, then this function is not called again.

Is there a problem in not just generating the meshes when called?

– Dale


(Menno Deij - van Rijswijk) #19

I’ll have to check if that does not negatively impact the performance. And I think I also saw this even when the render mesh was created, but I’ll have to check that too to be sure.


(Dale Fugier) #20

I am not seeing additional calls to CMyCustomObject::CreateMeshes once the mesh is created.