Sound Development

[Robert The Rebuilder]

That's what I was going to say - try reversing the normals. When I was developing the plugin's soft volumes for lighting, I had found that I needed to invert the normals from what I thought was intuitive.

I wonder if the visibility-related soft volumes also need to be reversed...

[Paradox]

I have to say... I looked at the softvolume code, blinked a few times, tried to see what on earth was going on, and quickly closed that file with a "DO NOT TOUCH" notice on it

What's with the whole "multiple the normals by -1 and do something involving (1-e)"?

[Chacal]

This would be a good time for Cyan to step in: "Hi! Here are the specs for all Plasma-related objects and code!"

[Paradox]

Uhm, yeah...

Inverting the normals didn't help either.

[Robert The Rebuilder]

I have to say... I looked at the softvolume code, blinked a few times, tried to see what on earth was going on, and quickly closed that file with a "DO NOT TOUCH" notice on it

What's with the whole "multiple the normals by -1 and do something involving (1-e)"?

Welcome to the confusing world of soft volumes!

Since the SV plane's vectors in Blender space seem to be opposite from the URU plane vectors, the normals are multiplied by -1. This is done right after importing or right before exporting, so that what you see in Blender is intuitive to what you expect: the normals point towards the inside of the soft volume.

The plConvexPlane contains the fields ScaledNormal and ScaledDistance, which uses (1-e) times the normal. The value of (1-e) = .998047 is the observed value from various URU SV plane scaled normals. As for why they need these scaled normals, I have no clue.

[Aloys]

so that what you see in Blender is intuitive to what you expect

This is the correct way of thinking when developping PyPRP (or anything else for that matter)

[Trylon]

it was the basic design principle behind the refactoring of the drawable code as well.