Rendering model in black?

In iRhino, when I rotate the model, colors appear as expected, but when I lift my fingers off the screen, the entire model becomes black.

Hoping this is some kind of lighting setting—advice?

~Dave

UPDATE: Rotating the geometry so that all of it was in the positive Z dimension seems to have cured the problem. It now renders as expected both with fingers on the screen and off.

All geometry in the prior “black” renders was in the negative Z (due to file exchanging with a Solidworks user). I had simply rotated the CPlane in Rhino for convenience, then opened the file in iRhino.

Did not test this behavior with any other files, but if negative Z renderings are black as default behavior for iRhino, a “Feature Request” would be for negative Z objects to render properly by default. Or, if there is some good reason for this (not sure what it would be, but maybe?), perhaps a setting to permit proper negative Z renders in iRhino Prefs would work also.

~Dave

Ah, I understand. That would be a problem. I’ve got a TODO list item for myself to work on that. Could you please send along a sample file where this is happening? I want to make sure I’m fixing something “real world” - so that I’m not “making up” what I think is the problem.

@dan: Sorry for the delay in responding. I wanted to do some testing and do have a few small things to report.

  1. I’m not sure if Negative Z is the sole issue. Seems like it is Neg Z plus something else which is TBD (file size?, blocks?, other?). I tried this small file in Negative Z and iRhino rendered it fine. Top_Z_Down.3dm (380.5 KB)

  2. However, the black rendering in iRhino does persist for this particular file where geometry is in the Negative Z. As mentioned in my OP, iRhino rendered it properly once I selected all geometry in Rhino, rotated it into Positive Z, then opened this new file in iRhino.

Let me know how I can get this file to you confidentially (it’s a client’s project, so I can’t post it here) and you can play around and try rotating to Positive Z, then opening in iRhino, if you like.

Incidentally, the difference in file size between Save Small (which, as we know does not render in iRhino) and saving regular is almost double, adding 30 meg! Does assigning materials really add that much size to files or is there something else at work?

~Dave

@dan: I uploaded the file in question through your upload page (which I foolishly did not locate earlier!). ~Dave

Awesome! Thanks Dave! I see it. (I was just about to ask you for it.) I will take a look at this for the 2.1.7 release of iRhino 3D (2.1.6 is already in the App Store pipeline) and see if it is an easy fix. I suspect it will be.

Much appreciated!

Dave-

Sorry this got away from me. I think I finally found the source of this bug and fixed it. Your model helped me figure it out. As you suspected, it had nothing to do with negative Z orientations; but rather with a subtle difference in how the different shaders (one for orbiting/panning/zooming; one for final still images) handled back-facing normals.

I’m going to get this fix - and a couple others - in an app update and submit to the App Store very soon.

Thanks again,
-Dan

Glad to hear you located the problem!

~David

DigiFabLab
814-321-5229