sprite rendering artefacts

[nomad]

Hi there!

I've found the strange thing happend when I'm trying to render the sprites. The artifacts is in the shadows -- The strange lines, perpendicular to the light source.

The light's shadow is set to the Depth Map Shadows. (with the Ray-Traced shadows everything works fine).

Is it normal or may be I made a mistake?

Here is the the thread from five years ago, looks like they have the same issue

http://forums.odforc...adow#entry36486

But I am curious about if other houdini users have the same problem in Houdini 12?

P.S. sure in some cases I can get around the problem by lower Alpha down to the life's end , as I show in figure #3 ( posted below. But it is a cheating. In the figure #3 (a) alpha is 1 and the artifacts is obvious..

Just in case I've also attached the file

sprite_shader_ALT.hipnc

[old school]

What part about rendering smoke as sprite cards is not a cheat?

As I mentioned in the other thread, the issue is that when the shadow map is being rendered from the Light's point of view, the sprite cards re-orient themselves to the camera render view, that being the light.

When you then render the cards through the camera, the cards now orient to the render view which is an entirely different orientation than the light. This means that the shadow map generated from the light contains shadow information that is not correct for the given render frame.

The larger the sprite cards, the more pronounced the effect. Your sprite cards are huge which exacerbates the shadow error.

You can crank the shadow softness parameter up to say 2 to add error to the shadow map to counteract the error in the re-oriented sprite cards but you will loose detail in your shadows.

Miguel in the last post doesn't run in to this mainly due to his sprites being very small and with the default shadow softness setting, it reduced this artefact to the point where it is negligible.

There is an existing RFE to have an option on the light to have sprite cards orient to another view object (your render camera) so that the generated shadows would be correct.

Knowing this, the less opacity you have on your cards, the less internal shadows are generated the less the error you will see (less in shadow = less error).

Raytraced shadows happen when the view is rendered through the camera eye and the cards are in their final orientation. That is why raytraced shadows work. You can use the new Stochastic transparency option in the Mantra output driver to tune this if you choose to render this in combination with hard surfaces.

----

Instead of sprite cards, you can render as instance spheres but that too has fallen far out of fashion.

Why not just render instance volumes instead of sprite cards? The instance geometry can have a density volume, rest volumes and a unique point ID to render this properly? You can apply your noise based on the rest with scale and offset based on time and unique ID for a seed? The instance volumes will orient to your point's velocity vector and up vector (if present).

The Volume Procedural can also be hijacked to render points as dense clouds? That way Mantra is only rendering a single volume instead of hundreds or thousands with the instance volume technique. Search for the pyroclastic smoke thread here on od-force for some ideas on this.

[nomad]

Thank you for your detailed explanation and wise suggestions, old school. I always appreciate them.

As you might guessed, the final Miguel's comment in previous thread spreaded a vague doubts in my mind, that is why that thread didn't convince me finally. Now all doubts are gone.

As for Raytraced shadows, I've already explored the stochastic transparency which is really helpful feature, thanks for pointing it.

Now I am going to explore your suggestions one by one.

In addition to sprites issue. You were wrote:

There is an existing RFE to have an option on the light to have sprite cards orient to another view object (your render camera) so that the generated shadows would be correct.

..where I can find it? Is it some kind of extension which I have to upload or just hidden parameter which I can add?

[riviera]

Why not just render instance volumes instead of sprite cards? The instance geometry can have a density volume, rest volumes and a unique point ID to render this properly?

This is an excellent idea! (I'll try to remember this next time I have to do "semi-sprites" )

Edited November 5, 2012 by riviera