Raytrace difficulties

Another problem.

I’ve been trying to get raytrace working in the render panel. I’ve tried loading it via TestPackageManager. After finding rhino-render-next and installing it via the package manager, the command rhino-render-next doesn’t work. There is no alternative render engine in the render settings.

After my periodic testing of v6, I’m inclined to go back to v5 yet again. I keep thinking surely, after all this time, v6 should be working.

OK, solution found to the lack of materials. What a waste of time it has been. I’m sure the shading section of the preferences was not there before resetting to default. I had been searching and searching. Then I saw it appear before my eyes as I clicked the button.

That is weird indeed.

Rhino WIP should work better in that regard.

And going back to the problem of all the surface edges showing, in that same ‘shading settings’ is the X-ray all wires. Which I guess was turned on but inaccessible like the render material option.

I’m much happier with it now. Finally feel like I can do something really positive with raytrace.

Incidentally, @nathanletwory, is there a way to make use of CPU, GPU and iGPU to speed things up?

So is it now not possible to use in v6?

In v6 an AMD GPU should still work for rendering. In v7 (WIP) unfortunately OpenCL is no longer supported (due to lack of proper support from Apple).

Well, ViewCaptureTo* commands should still work in v6, and are much faster than the rhino-render-next plug-in even if they use the same render engine in the background.

The performance improvements we managed to do in Rhino WIP are the result of some pretty big under-the-hood changes that are not portable to v6.

The denoisers that will be available for Rhino WIP/7 will make a huge difference in time needed to render, btw. Also not v6 stuff, unfortunately.

With transparent background turned on the results are terrible. Seems to just produce an alpha channel type output. Anything solid is black. Is this a known issue?

Not known to me. I just did a quick test to ensure it works as intended:

  • Create Model
  • Set Transparent background in Rendering panel (not strictly necessary)
  • -ViewCaptureToFile with Transparent background enabled

    used only 5 passes, because I didn’t want to wait for ages to test
  • I tested with this version Rhino 6 SR26 2020-5-26 (Public Build, 6.26.20147.06482, Git hash:master @ 7788f6214ee9335d5793cc6177985a1c745e663b) and Rhino 6 SR27 2020-6-24 (Public Build, 6.27.20176.04592, Git hash:master @ ba2c30de00be5a8b210bc297715204e941911799)

@robinp @nathanletwory more testing between Raytraced & ViewCaptureToFile and Rendered in V7, 2 different results :person_shrugging::person_shrugging::person_shrugging:
I’ve been having these issues for a while- see this thread

1 Like

I did a similar test to demonstrate. This does not always happen. And sometimes it is just part of an image that is black (perhaps a different issue). But I think this particular problem occurs when having transparent background selected in viewcapturetofile but then saving out to jpeg.

The images below are:
1- transparent background on saved to jpeg
2- render view (not raytrace)
3- raytrace with transparent background turned off

Hi @robinp

One thing I see is that you can not save transparency to jpg, that format doesn’t support transparency. Instead you should use a format like png or tiff. Having said that, the result you are having is not expected IMO, you should be getting the image with the background but not black.

I did a few tests and I’m also experiencing problems with this. This is running the latest WIP

1.ViewCapture_TransparentBackground saved as png

2.ViewCapture_NormalBackground saved as jpg gave me a blank image

3.Rhino-Render_NormalBackground as png

4.Rhino-Render_TransparentBackground as png

5.Screenshot of raytrace viewport

@nathanletwory I think images 3 and 4 are incorrect, it’s more noticeable on 4. They shouldn’t have those ambient occlusion shadows around the silhouette as if the building was placed on the ground, there is no ground in this image and there shouldn’t be any kind of contact shadows around it as you can see on image 5 screen shot.

Cheers,
José

Thanks, yes, I know that jpeg doesn’t support transparency. But it also shouldn’t produce the alpha channel when saving as jpeg.

Anyway, just had a weird one. Similar issue, but this was saved as tiff.

1hr 500 passes viewcapturetofile is completely black (no point in posting the image).

Same view from the viewport:

Ok, just waited 2hrs (!!) for another render. Slightly different view but the same result.

I’ve opened it up in Affinity Photo and it actually insn’t entirely black. There is some transparency.

Something very wrong is occurring. The machine was definitely working very hard for 2hrs but primarily produces black. The file is ~20MB for an image that’s about 2500x2000 px.

I just don’t get it; why is this black?

Definitely Raytrace on Mac is not working reliable at all, I’m also experiencing weird results. Are you using V6 or WIP here? How did you save your image to disk?

1 Like

V6.

Not sure what you mean about how I save it to disk? I select ‘browse’ and then use the MacOS dialogue to choose the location.

They are saved on a NAS.

Incidentally, another bug that has existed all the way through the V6 WIP and still exists:

The cancel button when doing a viewcapturetofile doesn’t work. You can click it as many times as you like to no effect.

You can tap Esc key and that similarly has no effect.

I discovered yesterday that Apple key + . (Old school Apple shortcut there!!) works immediately.

I meant if you were using viewcapturetofile or instead using the WIP you can run _render and then save from the Rhino render interface, but if you are running V6 the only option is the one you’re using.

1 Like

I am unable to reproduce the issues myself, but I asked a coworker on a Mac with AMD GPU to try and he was able to reproduce.

I have created https://mcneel.myjetbrains.com/youtrack/issue/RH-59380 to track this issue.

2 Likes

Thanks for looking into this.

I had one where it was only part of the image. Perhaps a different issue? See here:

Given the description in you track, it sounds like if I set cycles to use the CPU instead of the GPU it might avoid the problem?

Another thing, with the previous image I posted (that had a small amount of transparent background but was otherwise black), I’ve restarted my machine and it has now rendered OK.