We are developing a 3D star render in Houdini for our current planetarium production.
It imports the 3D position, color, and brightness from star catalogs such as Hipparcos:
https://www.cosmos.esa.int/web/hipparcos/catalogues [www.cosmos.esa.int]

Currently, I have two passes, a core pass, and a sprite pass.
The core pass uses points with pscale based on brightness and distance from camera. The core pass renders relatively quickly.
The sprite pass uses a small image for the star glow with varying opacity.
The challenge is the sprite pass render is taking significantly longer. e.g. ~20 minutes for a 2K square render.
Our target resolution is 4K square, which will take a prohibitively long time to render.

My understanding is the challenge is that Mantra has to ray-march through each sprite for pixels that are not fully opaque.
When we have thousands of overlapping partially transparent sprites, the number of marches can climb into the 1000s.

Ideally, what we need is a custom renderer that just accumulates the brightness of overlapping sprites.

Over the years, I have seen Houdini posts of custom renderers written in VEX and VOPs.

Does anyone have any suggestions on how one would go about writing a custom sprite brightness accumulation ray-marcher?

Keeping in mind it would need to be compatible with the custom fisheye lens shader that Matt Blackwell developed (see earlier post).

Please find attached examples:

• star glow sprite
  
• 2K square polar/fisheye render of star sprites. ~17 minute render.
  

Any suggestions would be much appreciated.

Thanks

Do you need sprites?

You can make fuzzy rendered points by ramping s and t values in a shader. This could be changed per point somehow if you had a database with the relevant information.

Soothsayer
Do you need sprites?

You can make fuzzy rendered points by ramping s and t values in a shader. This could be changed per point somehow if you had a database with the relevant information.

Good to know. But wouldn't we still run into the same problem with transparency ray marching?
I'm looking for a custom renderer that accumulates overlapping brightness and ignores alpha.

Thanks

jlapre

Soothsayer
Do you need sprites?

You can make fuzzy rendered points by ramping s and t values in a shader. This could be changed per point somehow if you had a database with the relevant information.

Good to know. But wouldn't we still run into the same problem with transparency ray marching?
I'm looking for a custom renderer that accumulates overlapping brightness and ignores alpha.

Thanks

Are the stars different depths? Because you could put a shader on a sphere and use a pointcloud lookup in the shader to loop over the points in the neighborhood of the shading sample. Basic texture splatting. Then there's no need to do ray accumulation of transparency samples. The number of iterations in the loop may still make it just as slow however.

jlapre

Soothsayer
Do you need sprites?

You can make fuzzy rendered points by ramping s and t values in a shader. This could be changed per point somehow if you had a database with the relevant information.

Good to know. But wouldn't we still run into the same problem with transparency ray marching?
I'm looking for a custom renderer that accumulates overlapping brightness and ignores alpha.

Thanks

I don't know but I've rendered a lot of points that way and never had any trouble.

jsmack

jlapre

Soothsayer
Do you need sprites?

You can make fuzzy rendered points by ramping s and t values in a shader. This could be changed per point somehow if you had a database with the relevant information.

Good to know. But wouldn't we still run into the same problem with transparency ray marching?
I'm looking for a custom renderer that accumulates overlapping brightness and ignores alpha.

Thanks

Are the stars different depths? Because you could put a shader on a sphere and use a pointcloud lookup in the shader to loop over the points in the neighborhood of the shading sample. Basic texture splatting. Then there's no need to do ray accumulation of transparency samples. The number of iterations in the loop may still make it just as slow however.

Yes, the stars have 3D coordinates, which the camera will fly between them. So you will see some fly past camera, while more distant stars will overlap. There will be parallax.

I thought it was the alpha ordering of which object is in front of another, making the render expensive.
Wouldn't just letting the brightness stack up of overlapping sprites be faster? With the understanding that some of the values will end up > 1. i.e. just use the brightness value, not transparency.

Hey Jeroen,

I did the sprite star render thing a long time ago (2009)and the render times were indeed heavy. The best way I could optimize in Mantra was by fading and culling any sprites below a certain brightness.

Creating a custom renderer for stars was also done at AMNH before I was around (and it was FAST) but we switched in order to enable star interactions with things like volumetrics and glow occlusion effects when objects passed in front of stars. But you could probably do a custom renderer in Houdini with a fog shader (that's how PBR used to work after all)... or maybe scattering rays in a smart way with the lens shader.

Recently I just rendered stars as points and did the halo in comp. It makes your comp heavy to implement it in a fisheye-friendly way, but the flexibility outweighs the performance drop...

Cheers,
Jon