Speed on 10.5

#21

Ok, I will put some ideas down here…

  1. Adaptive sampling.

It seems that a lot of rendering time is wasted when a very plain area is passed 16 times.

The renderer should only give a pixel another pass if it looks like it needs it.

This should be calculated on a probability basis.

The likelihood of a pixel being re-rendered should be a function of the amount that the colour of the pixel has changed with each pass (if the colour has changed on each pass then it is a safe bet that it will need more passes, and the more that it has changed on average, the more passes that it needs).

However, this may cause a problem in the following instance:

If there is a plain blue sky and motion blur is on then the last frame in a pass will be the only one to change. Using the above method, this pass is not likely to be rendered as the algorithm will have decided that it is not likely to be needed.

However, some pixels in the last pass will be rendered as it will be done on a probability basis. This will cause a stippled effect where there is a pixel rendered here and a pixel not rendered there. This would be dealt with partly by the soften option that has already been implemented. Also, any texturing or film grain would hide the stippling. Also, if this method increases the render speed then there can be more passes resulting in better quality where it counts.

IT might be a good idea also to have each pixel rendered in a different pass order. In the method above, the first pass will always get rendered and the last one is the one that will get left out so the pass order should be shuffled per pixel.

The probability of a pixel being rendered could also be adjusted on the basis of the previous frame or frames.

2 User defined sampling.

It would make sense to have the sampling probability adjusted by the user. If there is a high contrast, important character in the foreground then they should get more passes than a lower contrast simple background object. It might even be possible for the renderer to work out what objects in the render tree will need more passes so that this can be done automatically.

  1. Adaptive ray-traced shadows.

Where you have more than one sample on a shadow, you can end up with a stippling effect. This is particularly noticeable where the light is large and the shadow is far away from its source object. Since a ray-traced shadow knows how far from the source it is then it should be able to adapt so that it renders more samples where it needs it (further away where the penumbra is more spread out). A maximum and a minimum level could be set on the number of shadow passes for each light. It should also be possible to calculate where there only needs to be one sample (where there is no penumbra).

  1. Under- sampling.

There could even be under-sampling where passes that are considered to be unlikely to make a big difference would render with larger pixels. This method would be in-compatible with the shuffled order method.

Aside from this, I suspect that the lower level code could be optimised somewhat.

Please tell me if I am talking rubbish as I don’t know much about this stuff. Do other renderers do this kind of thing?

Cheers,
John.

#22

1 & 2 are something I’ve been asking for for awhile here. Why Hash hasn’t done it, I’ve no idea. I’ve used AA since polyray in the early 90’s- it’s a kick ass simple solution.

Again, why Hash chooses to not bother, is anyone’s guess.

3 seems good to me.

4 is the only one I’d probably never use. I’m pretty uninterested in providing Hash any tool they might use in their FINAL quality stages that would worsen the product more. As a DRAFT tool, it sounds reasonable, but my draft renders are already fast enough for me.

Good suggestions, well-written and clear. I’m too much a cynic to bother anymore with Hash at this level, but good luck!

#23

Ok, good to hear conformation. I will post it right away!

#24

Personally, I think Hash should partner up with Splutterfish and give us a pared-down version of Brazil for rendering. A:M would be practically perfect then :slight_smile:

Actually, the more I learn about building good materials in A:M, the more I’m convinced that creating high-quality renders is feasible. However, the speed issue is still there… A:M can take minutes to do what other renderers can do in seconds.

Integrating Brazil into A:M would still kick butt though!:buttrock:

#25

I think that everyone would love to have Brazil but I’m not sure weather this fits with Hash’s “build it yourself” philosophy.

However there is no harm in doing a bit of matchmaking.

#26

I have contacted splutterfish about the possibility on an AM version of Brazil. This is basically what they said:

It would probably be at least considered by th eprogrammers but it is more likely that they will produce a standalone version that could have front ends written for it by a third party. This may not happen though. If it does then there is no way of telling when and it will probably not be soon.

I am just going to keep suggesting things to Hash for now. I am sure that they can do it. It is just a question of will I guess.

#27

You know, on the topic of this thread, I’d LOVE to see more 10.5 renders shared in this forum so I can see some of the output differences.

#28

John: blip
:slight_smile:

#29

If splutterfish did put out something that allowed third-party stuff to link the two, I know I’d look into programming it. I’d love to have the option of rendering via more than one raytracer straight from my project files.

Since AM files are simple text files and the data is all right there, I can’t imagine writing an app to link into a ready-made receiving end would be so terribly difficult. Might be a fun project.

#30

Originally posted by ZeBoxx
John: blip
:slight_smile:

Oops, I forgot to put my jammers on. He he he. :wink:

#31

Here is an image done in 10.5. Bias normals, porcilain, hairguides (self shadowing), large specular:

#32

Outside of that huge crease at the top of his forhead, that is SWEET! Nice work :thumbsup:

#33

Thanks for the compliment:) He is not finished yet and that crease will go. I had forgotten about it though. It is amazing how you can stop seing something like that.
I realy enjoyed making him. I looked at him in v10 today and thought “Oh my god! I can’t believe I used to put up with those creases” The only bias tweeking that I did in 10.5 was for MAKING creases, not getting rid of them. If you are using AM then save yourself some time and upgrade.

Oh, by the way, does anyone have a good technique for getting rid of the glowing lines under places like the chin? They are caused by the shadow map. Maybe I should use a luminesance map and make the crevices dark?

Roll on a faster renderer so I can use raytraced shadows…

#34

Hey John,

Great caricature! It really looks like you can add detail to a model without worrying too much about creasing. Do I detect a trend towards modelling heads and not bothering with the rest of the body?
Incidentlly, the ‘Bobby Charlton’ hair style is the perfect use for the new guide hairs.

So, the strange crease on top of his chin is the result of z-buffered shadows? This kind of inaccuracy is why I stay clear of them and prefer the raytraced ones.

#35

John:
Very impressive. It looks like I might have to swap to 10.5 now that it has gone beta. (Even though I swore not to after the
9.5-10 episode)
Any chance of seeing a wire frame? I’d love to see where the creases aren’t happening, if you know what I mean.

#36

Hi all.

Piquod:

Hello there. Yes, as I didn’t have to fiddle with bias handles, Adding new geometry didn’t make creases. All I had to do was to make the patches as square and even as I could and it renders fine.

And yes, you do see a trend for moddeling faces and not bodies. I have made most of a body for him though but my computer died again. I am writing this from a library computer. I havn’t made many bodies because I am afraid of rigging.

Squeekypics: I will post a wireframe when my computer is fixed (hopefuly tommorrow)

Cheers all

#37

I’m just curious, how long did it take that hair to render? And also, what kind of improvements have been made for hair in 10.5? Is it useable yet? Just wonderin…

-Brian

#38

The hair didn’t take too long to render considering that it was self-shadowing. However there is not much of it there and I was using a z-buffer shadow. I can imagine that lots of hair and raytraced shadows would kill renderspeed but then that is the case for other renderes too.

Other improvements: Controll over crinkle amount and frequency + hair renders in mirrors etc (raytrace compatable). I am not a big expert on hair rendering though so I don’t know what else to expect. I would like to be able to have the colour vary from hair to hair and allong the hairs length but maybe this is asking too much?

#39

Here is the wire for those who wanted it. It orrigionally had many more patches, partly because I was using doubled up splines for making creases. I decided to just use the magnutude instead. I cut the patch count by a third! I never use maintain curvature by the way. I just add/remove geometry and then shift the cps about to make the patches even. I am OK with this as it doesn’t take long and I get to refine the shape as I go. Sorry that he is small, he wouldn’t attach otherwise.

#40

Thanks very much for that. Some very elegant splinage there. I’m inspired!
sigh
It looks like my creasing issues will be sorted out by a lot more modeling practice :wink: