Objects which reference material images show in black when rendered

[coffsoft (Garry)]

Hi Jeff. Good thought, but not the money shot this time. I have attached the images.

For the record, I updated Rhino again a few days ago…

Version 6 SR14
(6.14.19078.12411, 19/03/2019)

I also upgraded from Windows 10 1803 to 1809 yesterday.

The first image shows the objects which are selected using Select Objects from the Kitchen Cabinets Base material. At this stage, those 3 objects are still black, as intended. Note that Select Objects was clicked after the other objects had turned black. That confirms that the material registrations are intact, even though the rendering has gone astray.

You will note that the floor is grey instead of the boards image.

The second image shows the 3 objects in green after the colour change to the Kitchen Cabinets Base material. The other objects are still black.

The third image is inverted without the floor.

[jeff (Jeff LaSor)]

Thanks Garry (@coffsoft)

Dang… Well, I’ll keep digging… I still haven’t been able to reproduce it here… What I’ve done to try to automate it and/or or speed up the occurrence of the problem is I run the TurnTable command on a maximized viewport… I let it run for about 20 minutes, and then I try CTRL+S, File->Save, File-SaveAs,…and other commands…but still, everything looks good here…

So, I’m wondering if you did the same thing, does the problem appear? Hopefully it does not… because that means similar tests produce different results on different configs…which is an even bigger nightmare to track down… If we both can come up with a series of steps that produce the problem on both our machines, the problem will be as good as solved. Unfortunately, until I can get it to happen here, and watch it happen in the debugger, it’s going to be very difficult to figure out.

Thanks for all the effort thus far, it is much appreciated.
-Jeff

[coffsoft (Garry)]

Hi Jeff. I have spun the full screen Perspective view for a few minutes a couple of times, with view changes, switching to other Windows applications, property drill downs, etc between spins. I have included some saves as well. So far no black. I will keep trying.

It looks like the debug facility is not available to me. I thought that I might be able to capture the trace here, but probably not.

Regards, Garry.

[coffsoft (Garry)]

Back again.

I have edited this posting quite a few times today. There is plenty in here. Please do not respond until you have considered the paragraph which starts ‘Later…’.

I have another idea. You mentioned earlier that the problem is unlikely to be related to my GPU. A few days ago I introduced a tenth Layout page, which contains 3 Details, each with a Rendered image. I have had frequent failures when trying to print that page via PDFCreator. Rhino simply closes midway through the print process. I have attached an image from such an attempt. The progress bars advanced slightly after the image, then Rhino closed. I have restarted many times, even after closing some other applications, but it will not print. I have managed to print the page a couple of times in recent days. For the record, Page 9 contains 7 Details, each with a Rendered image, and it prints via PDFCreator with no problems. Observation suggests that Page 9 has more content and is more work for Rhino to print, as it takes longer to produce than Page 10 takes when it is successful.

I copied Page 10 to create Page 11. I then deleted one of the Details from Page 11. It printed successfully via PDFCreator. I then tried to print Page 10 with all 3 Details. It started, but then Rhino closed again.

Could I have other resource issues which are resulting in this and the black objects? I know that the PC is old and slow. I am looking to replace it. Just a thought.

I found something useful… Is it time to take option 3 in the NVIDIA page below?

The description for Event ID 1 from source NVIDIA OpenGL Driver cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

**The following information was included with the event: **

A TDR has been detected.
The application must close.

Error code: 7
** (pid=9812 tid=3880 rhino.exe 64bit)**

Visit OpenGL “TDR detected” Meaning | NVIDIA for more information.

https://answers.microsoft.com/en-us/windows/forum/windows_10-hardware-winpc/windows-10-display-driver-has-stopped-responding/5caff7ea-bed5-4111-baac-e72d32d4dbe2

There was no TdrDelay key, so I created it. I tried values 3, 5, 8 and 10 with Windows Restart after each change. I also tried QWORD instead of DWORD. Page 10 still failed with each setting. Does this ring any bells with you?

The link below suggests that the TDR value can be set via the NVIDIA control panel. However, my old GeForce 555M Control Panel does not have that facility. That suggests to me that TDR override capability exists only on later GPU models. That could be the cause of my troubles. New PC?

http://developer.download.nvidia.com/NsightVisualStudio/2.2/Documentation/UserGuide/HTML/Content/Timeout_Detection_Recovery.htm

My GeForce 555M Control Panel…

Later… At around 3:31 pm, the black problem occurred again. I have attached another image of the event log below. There is no reported error, so it seems that the original black problem is not related to the printing problem. I am interested in your thoughts.

Regards, Garry.

[jeff (Jeff LaSor)]

Thanks Garry,

Ya, TDRs aren’t going to be the problem here…if/when you get a TDR, the whole system will freeze, while Windows shuts down and reloads the video drivers…you should also see/get a little popup bubble in the lower right corner of your screen stating as such… Microsoft introduced TDRs with Windows Vista, and immediately realized that their default delay was way too short, and wreaking all kinds of havoc with all kinds of programs… Rhino’s installer at one point was setting the delay to some high value because of it… However, things have calmed down quite a bit, and later versions of Windows actually allowed drivers to configure the value based on their own feedback. Long story short…this isn’t what’s causing your black objects… The black object problem is 100% Rhino…now, it might be due to your video card and/or memory, but from where I’m sitting, your card and its 3GB of memory should be working just fine. I’m still hanging on the assumption that there is something specific about what you’ve done in your file and how you’ve done it that is confusing Rhino… Have you ever seen this problem with any other file? I know this is a lot to ask, but starting a completely new file, and adding geometry and materials over time, are you able to reproduce the black objects? Note: Do not try copying and pasting from the problem file, that could potentially copy the “problem” and produce a false positive.

I’m still hopeful I can reproduce the problem here, and will be trying it on other configurations this week.

Thanks again for all the effort, it is much appreciated.
-Jeff

[jeff (Jeff LaSor)]

Hey Garry,

Not sure why I didn’t think of this before…but …

Is your Rendered display mode set to its Default Values? Or have you made any changes to the Rendered settings?

Here’s something else I’d like you try when you have the time…

I’ve saved your file out to something that only contains the geometry…all textures, plugin-data, layers, etc… are gone…just pure geometry.

1. Open the attached file
2. Start assigning materials to objects (keep the organization “flat” at the moment (i.e. no layers))
3. See if black objects start occurring.
4. If no black objects, then start creating layers as you did in the original file.
5. Basically keep working in the file as you would the original
6. See if black objects start occurring.

…the method to my madness here is that I’m trying to see if the problem is indeed related to something in the original file… However, if you’re able to start getting the black objects in the stripped down version of the file, then clearly it’s NOT “file related”…which means the problem is pointing more and more towards your configuration (Ugh, that would be bad)…

Just to make sure you’re starting with the right thing…this is what your Rhino should look like after opening the attached file:

Thanks again!
-Jeff

HouseRemodelHBlackReducedStripped.3dm (2.3 MB)

[jeff (Jeff LaSor)]

Oh ya…

7. Start creating layouts. It’s possible that these are really what’s causing the problem…

-J

[coffsoft (Garry)]

Hi Jeff. I have attached the settings from my copy of the file. I will try your file and follow your guidelines.

I have not seen the black objects in other files. However, I have very few active files at the moment, and the others are relatively small and simple.

Rhino3DOptions.ini (136.4 KB)

It did not take long. I added 4 materials, then spent some time zooming, saving, rotating etc, and the black appeared. I only reached step 3 in your list. I have attached the updated file.

HouseRemodelHBlackReducedStripped.3dm (3.2 MB)

Regards, Garry.

[coffsoft (Garry)]

Hi Jeff. I hope that you are well. The gremlin is still present. I have applied a few updates recently, including the version shown below earlier today.

Version 6 SR14
(6.14.19106.18421, 16/04/2019)

It seems that I can apply changes to the model over a prolonged period, and then after using Ctrl S to save, the black objects appear. That seems to be a consistent trigger, but it might not be the only trigger.

Regards, Garry.

[coffsoft (Garry)]

Hi Jeff. Another symptom appeared today.Printing via PDFCreator is introducing black blocks. In this case, the Rhino model does not always display the black blocks after the print operation, so it is confined to the PDF output.

In one instance, Rhino crashed out during an attempt to print the page shown below. On that occasion, the model had been opened and the print attempted immediately, without any changes to the model or the view.

I am wondering whether it is due to heat stress on my laptop . I might be tilting at windmills here, but at the moment the laptop is reasonably warm around the exhaust vent.

…10 minutes later… I closed about 10 web pages in Google Chrome, keeping 45 pages open, and restarted Rhino. I was then able to create the PDF pages. This might not be cause and effect, but it is food for thought.

Have you been able to reproduce the behaviour?

Regards, Garry.

[jeff (Jeff LaSor)]

Thanks Garry for the details…unfortunately no, I have not yet been able to repeat anything remotely to the issues you’re having…

Based on your latest findings, I’m starting to wonder if this is a “contiguous memory” issue you’re running into. Are all of the black objects using materials that use/reference at least one texture file? I ask because all textures must occupy a contiguous chunk of memory and cannot span across segmented memory blocks… It’s possible that the drivers are simply losing the battle to meet that criteria. I see you have 3GB of video memory, which I would think would be plenty atm… but perhaps you are pushing those limits… based on the files you’ve sent me, I certainly don’t think that’s the case… but I just don’t know what would be causing this behavior.

If the black objects are using a texture… what happens if you go into the Material Editor for that texture (when the object has gone dark) and “uncheck” the texture channel? In other words…remove the reference to the texture file from the material. Does the object then display in its “diffuse” color? …assuming this is even the case. If so, does checking the texture channel again make the object dark again?

I think a better way to approach this (or at least another attempt ), is see if you can determine what “brings the dark objects into the light” … and if/when you discover that, does doing the opposite (undoing) push them back into darkness again? Isolating that type of thing will identify what’s actually causing the object to display dark, which I then hope will point to what/where things are going bad… I still won’t know why, but at least I’ll know what’s getting corrupted…which may lead to other ideas and possibilities.

Thank you very much for all of the feedback you’ve provided, and more importantly your patience on this. I’m sure it’s frustrating for you…but again, until I can reproduce it here, I’m most likely not going to be able to fix it…so we just continue the back-and-forth and try-this and try-that’s until we come upon a possible “Ah-ha!” moment.

-Jeff

[coffsoft (Garry)]

Hi Jeff. Having spent a lifetime coding, I understand the challenges that you face in problem determination, isolation and debugging. The quote below is from posting 14 above. It confirms that the black objects do not appear to differentiate between those which have a material registered and those which do not.

I set out to try your suggestion of unchecking and reinstating by making some minor changes to the model, then saving. This time it really went nuts. Instead of shading selected objects black, it turned the entire view black. Switching back to Wireframe showed correctly, as did switching to Shaded, Ghosted, etc, then switching back to Rendered showed a completely black view. I then switched from Perspective to Top, and saw the same behaviour. To be clear, the only thing in the full view rectangle was the view title ‘Perspective’ or ‘Top’.

I tried to get an image of the completely black view, but it then showed the rendered model on the normal background with selected objects in black again - the usual problem. The images below show the black images before unchecking the Texture, after unchecking it with the diffuse colour correctly displayed, then reinstating the Texture, which redisplayed the objects in black.

The most obvious trigger for black objects is the Ctrl S save function. That has a very high rate of resulting in the black objects, but the set of impacted objects varies - it is not always the same objects.

Another trigger seems to be elapsed time over which changes are applied to the model. Sometimes black images appear without the save function. Sometimes it happens after a model rotation or zoom.

Does that get you closer to the ah ha moment? Let me know if you have another set of steps for me to try.

@coffsoft

Many of the surfaces which are black in this image have simple colour assignment without materials. Further, one of the textures has displayed correctly, as have some simple colours.

Regards, Garry.

[coffsoft (Garry)]

Hi Jeff. Here is a new twist. I have been making some changes to the model today, and after a while, some objects were displayed with a different material. Instead of bricks, as defined in the material Endeavour, the objects displayed concrete blocks. I captured image 1 below, then saved the model without changing the material assignment, closed Rhino, then reopened the model. The bricks were there again, as shown in image 2. You will notice that the material assignment had not been changed, simply misinterpreted for display.

That suggests to me that the gremlin is within Rhino, not my PC. I hope that this helps.

Regards, Garry.

[coffsoft (Garry)]

Hi Jeff. I might not have mentioned that when a Save causes the problem, the active view is Perspective, already in Rendered mode.

Regards, Garry.

[jeff (Jeff LaSor)]

Hey Garry,
@coffsoft,

Just wanted to let you know I haven’t forgotten about this…and appreciate your ongoing patience and digging on this one… Something in one of your last posts makes me wonder if the material caching is getting messed up or confused.

Please try this (note: This is not a solution, it’s only for investigative purposes):

Start Rhino
Run TestMaterialCache

… The command line should read “Material Cache Disabled”

Now load your model and start working…and see if things go bad again.

Note: The material cache setting is not remembered across Rhino sessions, so you will need to do this every time you start Rhino… Maybe stick it in the Startup Commands section in the settings for now. Also, it’s a test command, so it won’t auto-complete…you need to type the command name in its entirety. Also, it acts as a toggle…so be sure that after you run it, the command line says “Disabled”…if it says “Enabled”, just run it again…so if you do put it in your Startup Command section, I would also verify that the command line reads “Disabled” after Rhino starts…if you have more than one startup command entry, then make TestMaterialCache the last one…that way, Rhino’s command line will show it last after starting.

Your Rendered view might feel a little more sluggish with the cache off, but if you never see the black objects with it off, then it’s a pretty good bet that something is messing up the cache.

Thanks,
-Jeff

[coffsoft (Garry)]

Hi Jeff. No luck. Image 1 shows the black objects after some time spent modifying the model. Image 2 shows the command being reversed afterwards.

Version 6 SR15
(6.15.19148.13161, 28/05/2019)

Regards, Garry.

[nathanletwory (Nathan 'jesterKing' Letwory)]

It would be interesting to see how the GPU RAM usage is. If you could install GPU-Z start it before Rhino, switch to see the sensors of your GPU. Then start Rhino and open up your model, pay attention to the GPU RAM usage. Does it hit 100% ?

[coffsoft (Garry)]

Hi Nathan. It hits the mid 80’s when I am zooming and rotating the Rendered Perspective. I have included some images below, as well as the GPU-Z log file. I opened the log file in Excel, and the highest GPU Load was 86%.

GPU-Z Sensor Log.txt (192.1 KB)

Regards, Garry.

[nathanletwory (Nathan 'jesterKing' Letwory)]

Thanks for trying. It isn’t the GPU Load I’m after, but the Memory Used. Based on your screenshots it looks like the textures all show up correctly. What I am trying to rule out is maxing out of your GPU memory when the black objects happen.

GPU Load is how hard your GPU has to work to put the model on screen.

[coffsoft (Garry)]

Hi Nathan. Max memory used is 716 MB for that session. I will try some more tomorrow, and see what it shows when the black images appear. Thank you for your help.

Regards, Garry.