Raytraced: GTX 10xx testing requested

Here’s some Viking history for you:
This is a 8.4 million polygon scan. Handling it is sloooow… everything is like mud, but once the rendering starts it does 200 iterations in just 18 seconds. It is very slow to handle in rendered mode too, well viewport manipulation is fast, but material changes and stuff is slow.

Also do you know what can be done to get rid of that horrible banding? That’s a show stopper for production use.

1 Like

Tested a simple interior scene with the default enviroment with a multiplier of 2. 2000 samples. It’s noisy, but has a nice realism to it:

And then sat the multiplier to 0 and added a rectangular light “in” the window. Lowered intensity to 10. 200 samples. Gone is most of the noise, but so is the realism:

Then pulled the rectangluar light back and up and made it 4 times bigger and an intensity of 100. 1000 samples, giving a good combination of speed and noise:

But as you can see the top image has the best realism.

Note: adjusting the lights is a bit of a hassle as they often do not update, so I have to move them (like the curve objects) for them to update, then undo to get them back to the right position. Then sometimes they are updated. Other times the adjustments are updated right away.

1 Like

This has to do with the (re-)build time of the BVH, and actually yesterday I got some info from one of the principle Cycles devs that I need to test - it can speed up that part quite a bit…

The banding is due to gradient converted into small data range. For HDR bg we need to improve the sampling that converts from big range to small range. Further possibly supporting rendering to float buffers would help (to some HDR format) That will be a bit kinky to get working properly in Raytraced though, since that currently only seems to work in background rendering (non-interactive, non-progressive refine).

1 Like

This is a symptom of the same problem as with object material changes, it should be fixed with the geometry overhaul I started last week.

2 Likes

Interior scenes could be improved quite a bit with the concept of light portals that Cycles has. Light portals are invisible objects that help Cycles with essentially optimising light paths for scenarios that exist especially with interior scenes: a window through which a skylight (or sun for that matter) does its thing. I don’t (yet) know how that concept could be easily presented to Rhino users without confusing them…

1 Like

Yeah, good point. And keeping it simple with Raytraced is key I think. Adding portals that only cycles support doesn’t make sense I guess.

Well, I think it would be good to early on think about a basic and an expert view on things (I guess the GH nodes could be that).
If you keep it all too simple, it will never be really usable for anything worthwhile.
Thea Render recently implemented a switch between a very simple (and for me personally totally useless) material presets view and a more advanced view that implements at least most of the basics of Thea materials inside Rhino (I personally actually use the full blown Thea editor that is also available).

Dumbing it down too much is a dead end street that too many tools these days are choosing. Nothing against a beginners view with simple choices, but there is something to be said for allowing users to advance, learn, expand their knowledge and get really good results instead of mediocre ones - and Cycles is capable of really good stuff as many Blender projects show.

In version 5 of Rhino, the included rendering options are/were crap on the level of 1995 render engines. Cycles holds the opportunity of lifting this up to something that can be shown with pride in 2016. So instead of dumbing Cycles down since rendering was so bad and primitive until now, I’d rather vote for adding really good material presets, good environment presets, good documentation and some video tutorials to help the users out of their (initial) confusion.
Confusion is the first step when you learn something new, not something to be avoided but sought after. And you get rewarded with renderings that look really good instead of so-so…

My personal view on this would be to add all the bells and whistles that Cycles offers, even if that is only accessible through Grasshopper or some expert view. If somebody is confused, educate him/her, don’t drag down everybody else.

Light portals exist for many years in many render engines, so it’s not as if nobody ever heard of them. :wink:
Could be an object property of the glass panel forming the window, a material property or a setting on an area light or a special light type…

Cheers,

Tom

Oh, I am all for giving access to the advanced bells and whistles, knobs and sliders at some point. But making sure the simple access works As Good As We Can Get It means that we have successfully used the advanced stuff as well. Once that is the case having the advanced stuff out there would be a minor step. The other way around would make development work much harder.[quote=“Thomas_Helzle, post:48, topic:37682”]
Could be an object property of the glass panel forming the window, a material property or a setting on an area light or a special light type…
[/quote]

Yes, probably something like that. But I’d like to ensure it gets added in a well designed way, not as an afterthought :slight_smile:

/Nathan

1 Like

That is fine with me. I personally am just constantly frustrated with the “simplicity” of some areas of Rhino, especially the render panel and settings, so I guess that is where my plead for depth comes from.

When I saw that the AMD ProRender basically tried to follow the painfully limited approach of the current Rhino rendering options, it made me cringe, especially after I saw how powerful it actually is in 3DS Max.
And hey, they even have real cameras there… :wink:

I look forward to the deeper parts!

Cheers,

Tom

Hehe,
I am pretty familiar with cameras in various CG apps and actually greatly prefer Rhino’s “tripod with stored locations and parameters” approach. No CG app I know gives me all lense-parameters via Mouse and Modifier keys.

There’s no discussion that one needs cameras as objects for proper animation – but for stills I find the default camera controls close to perfect: To me the closest match to walking around, and turning the lense ring for a shot. Do you know all of these?

Or can’t you live without the transform widget when setting up the camera ;o). The deeper parts in my case are delivered by the render-plugin.

Yeah, for navigating the viewport it’s fine, but for everything else a real camera that is an object and can be properly animated and located, can be used with or without a view goal etc. is much preferred by me.
I hate object handling in Rhino anyway, probably because I come from “normal” 3D software where each object has a pivot, a location, a place in the hierarchy, can be selected in the treeview even if invisible etc., but for the camera I find the CAD approach even more annoying.
But this is mostly outside the focus of this thread, I just couldn’t stop myself from making a stab at the - for me - worst camera system I ever used. :wink:

Cheers,

Tom

1 Like

Well, I was talking Camera setup for rendering and that I prefer it over over CG app implementations.
For serious animation one should use other tools anyway.

I hear you. These two things have been the biggest hurdles I had to take during the integration of Cycles. I have requested object pivots a few times, but I don’t think it will happen (any time soon, if at all) - some things would be so much nicer with the integration…

But all in all this all works somehow magically :slight_smile:

/Nathan

1 Like

Bug: I see that spotlights don’t support shadow intensity, nor light color. And I also noticed that when I deleted a spotlight the shadow was still calculated. Until I swapped display mode back and forth.

Oh… and Raytraced doesn’t support SubD… please add that! :slight_smile:
(For this I had to extract the render mesh of the SubD object)

Edit: Just added a box (made with my WIP sub-d tools) and a slightly gray material to the ground plane. Added some blur to the camera. It is lit with a single planar light and the environment is lowered. All took 30 minutes. Render took 17 seconds. If I was a jeweler I would be pretty happy with this tool and the results. I would wish for light scattering though :wink:

By the way, the “diamond” is just an unwelded modified mesh sphere, so no correct cut there.

3 Likes

Shadow intensity isnt supported as Cycles doesnt have that yet. Light color should be though.

Regarding SubD support - it isnt supported by the changequeue yet. As soon as @andy handles them in the changequeue they will automagically work.

Through the changequeue Cycles only ever sees RenderMeshes :slight_smile:

/Nathan

1 Like

Thanks, I will spend more time with it, as a jewellery modeller.

Regarding shadows, I see cycles support object ray visibility (object can be sat to not casting shadows) but in this thread it seems like they might have found a way to control shadow intensity.

Quote: “This value feeds the Mix Shader on the degree of transparency of the shadow rays only.” http://blender.stackexchange.com/questions/46911/how-can-i-make-a-shadow-disappear-in-cycles

I just did a test on the old GeForce 330M on my macbook running windows 10 and it automatically chose the i5 to render. It took 5:03 to reach 200 samples and that was also on a smaller perspective view. But it didn’t go byond 61% CPU usage, do you know why? None the less it did the job and even reached 11 samples during the 17 seconds it took the 1070 to reach 200 samples.

It indeed is old, at least CUDA 2.1 is required, your card is 1.2: CUDA - Wikipedia

On a multi-core machine not all cores are selected by default. If you want to use all cores (and thus get to 100%, and rather unresponsive machine) you can use RhinoCycles_SetThreads to change the thread count. If you give 0 you should see better CPU utilisation.

/Nathan