Michas Wishlist

[Micha_cg]

Re: Michas Wishlist

IM could be difficult, because it jump in rate steps -1 (50%), 0 (100%), 1 (200%), ....

Most I let it be at the same value, but my image resolution dosn't jump so much. And if I jump from 800x600 to 800x600, than I think about the best undersampling, because often I prefer shadow details at high res too.

[dalomar_cg]

Re: Michas Wishlist

Micha,

LC solutions are resolution independent, so you shouldn't have to increase your LC subdivisions just because of your image size only due to quality. Since LC uses percentage of the screen to dictate sample size, the only thing that you could do is lower that percentage for higher resolutions, essentially keeping the pixel/sample size ratio the same. However doing this increases noise, so although it may be useful to decrease this percentage for higher res, its is by no means a direct relationship. For large res I may cut the sample size in half (effectively quadrupling the number of samples) but it is by no means directly connected to the increase of the image compared to a standard test size. Hope this makes sense, but in the end the final resolution doesn't have too much of a stake in the quality of the solution...and infact if you use World for your sample scale, there isn't any refrence to resolution at all.

[Micha_cg]

Re: Michas Wishlist

I'm not sure I understand it, but:
(a) set subdivs at 800 and render a scene at 640x480. After time x the LC is calculated and looks quite good, no black unsampled pixels.
(b) now jump to 2048x1536. The LC calculation need the same time x like befor and the LC pass looks dark with many unsampled black pixels.

It could be nice to choose the resolution without to change the LC settings.

If I understand right, you mean, the sample size is an other factor that could be taken it acount. This is right and is similar to the IM undersampling. The relativ LC samples size is nice. I like it like it is. It makes, that the same relativ detail resolution is reached.

Maybe it's useful to implement two options like "fix subdivs/pixel" and "fix absolute sample size". But I think, the first one could be good for beginners and not-daily-users and the second one could be good for experts to speed up renderings. The first goal should be quality and if somebody need speed, than he could tweak the settings. But I think, advanced user dosn't need "fix absolute sample size", because this is better set manualy.

So, if an image looks nice at resolution 800x600 than it should look good at 3200x2400 too, like an unbiased scale up. If we say, a higher resolution could get less shadow GI details, thats a question of quality. I think, per default if an user set a higher resolution, than he should get the same quality, that means a higher resolution of GI too.

The current LC/resolution workflow is not user friendly. The user must change the subdivs settings, if he change the image resolution, bcause the LC subdivs are absolute values independent from the image resolution. All other options are relativ to the resolution.

[dalomar_cg]

Re: Michas Wishlist

(a) set subdivs at 800 and render a scene at 640x480. After time x the LC is calculated and looks quite good, no black unsampled pixels.
(b) now jump to 2048x1536. The LC calculation need the same time x like befor and the LC pass looks dark with many unsampled black pixels.

The only reason why there is a difference is because that is the way the calculation is being displayed. In the end, both calculations will trace the exact same number of rays and they will contribute to the same number of samples.

The issue becomes that you need to have a sufficient number of rays for a given sample. So if you decrease the size of the samples, you will need more rays (subdivision) to make sure those samples are accurate enough. There also is the issue of more samples causing more noise, and as you know more noise means more subdivisions to smooth it out.

So, if an image looks nice at resolution 800x600 than it should look good at 3200x2400 too, like an unbiased scale up.

In my experience most LC solutions look fine at higher resolutions, and their is no need to have a direct correlation between the size of the image and the size of the samples (in other words fixing the sample size based on pixels). I do typically keep my sample size lower then the default (default is 2%, and I keep mine at either 1% or .5%) but beyond those small steps, there isn't much more of a need to decrease the sample size.

The current LC/resolution workflow is not user friendly. The user must change the subdivs settings, if he change the image resolution, bcause the LC subdivs are absolute values independent from the image resolution. All other options are relativ to the resolution.

I don't think they are not user friendly...all essentially you need to worry about is subdivisions and more means better quality and less means faster. I'm not sure how much more user friendly it is then that. If people really want to squeeze more out of LC then I tell them to decrease the sample size as per my settings above. I really don't see to much of an issue with LC at all.

[Micha_cg]

Re: Michas Wishlist

Could be nice to enable/disable script rendering per command. For example, if I use my render button with sound at the end of the rendering, script rendering must be enabled. Could be nice, to enable script rendering, use the script and disable script rendering after the script is finished.

Could be add to the turntable tool buttons.

[dalomar_cg]

Re: Michas Wishlist

enable/disable script rendering...I have no idea what your talking about...

[Micha_cg]

Re: Michas Wishlist

Sorry -> script rendering = batch rendering

[dalomar_cg]

Re: Michas Wishlist

Okay, that makes more sense. That might definitely be a good thing to keep in mind for when we add scripting functionality (something Joe's been working on). I could imagine several scripts failing without that option, so I think we should definitely work it in there.

[Micha_cg]

Re: Michas Wishlist



Next wish: if the render output is not at the same ratio like the viewport, than the render window command cause, that the wrong selection is rendered. For example output is 1200x600 and viewport is 400:300. Or is this a wish for the McNeel team?

[dalomar_cg]

Re: Michas Wishlist

No it deals with how we work with the viewport. Allot of that can be cleared up if there is some integration between some of our options and Rhino's. Another place where this comes up is working with safeframes. Its something Joe and I probably just need to sit down with and find a solution.

[Micha_cg]

Re: Michas Wishlist

I try to create a button with a little script, that makes the same like I do manualy - material properties - edit. I try this:

_propertiespage _texturemapping ...?

and the material page is opened. But is it possible to get acess to the edit button per command? If not, Joe could you implement a command that open the Vray material of a selected object?

[joe_b]

Re: Michas Wishlist

If not, Joe could you implement a command that open the Vray material of a selected object?

Yeah- that probably wouldn't take much. We're adding some Rhinoscript functionality at the moment anyway.

[Micha_cg]

Re: Michas Wishlist

Thanks.

[Micha_cg]

Re: Michas Wishlist

New wish: some times I opem old scenes, but texture locations are changed. It's very difficult to set the right paths again and the automatic search dosn't work (is it a bug?). It could be nice to export a txt file with all paths, so that the user can edit it and reimport it.

[joe_b]

Re: Michas Wishlist

It's very difficult to set the right paths again and the automatic search dosn't work (is it a bug?). It could be nice to export a txt file with all paths, so that the user can edit it and reimport it.

The search doesn't look everywhere on the machine. It looks in directories off the 3dm file and I think after the service release it should look around whatever vismat files were imported.

We may add resource search paths to our options as well so if you generally store stuff in a certain folder(for example c:\textures or something like that) we can always search there. I'm not sure if that will be in the SR or not - but we can probably make it happen for the next major release.