[PATCH] Fix export of transformed soft volumes

Announcements and discussion regarding any projects related to Cyan Worlds' Plasma Engine including (but not limited to) CyanWorlds.com Engine, Drizzle, OfflineKI, PyPRP, and libHSPlasma.

Re: [PATCH] Fix export of transformed soft volumes

Postby Nadnerb » Wed Jul 16, 2008 1:32 pm

Awesome! ... oh drat, that means I left out the transform to the normals when rewriting the sv export. (while correctly transforming the positions) *doof*

Of course, instead of separating, inverting, and transposing the matrix, you could just:
Code: Select all
Nor = tmatrix * Blender.Mathutils.Vector(face.no)
Nor.normalize()

As is done for the vertexes two lines down.

Because for an orthogonal matrix

omatrix.invert() == omatrix.transpose()

A rotation-only matrix is orthogonal, so that's equivalent to inverting it twice:

tmatrix.rotationPart().invert().transpose() == tmatrix.rotationPart()

and if you're normalizing the vector in the next line, you don't need to separate out the rotation. ;)
Image
Live KI: 34914 MOULa KI: 23247 Gehn KI: 11588 Available Ages: TunnelDemo3, BoxAge, Odema
Nadnerb
 
Posts: 1057
Joined: Fri Sep 28, 2007 8:01 pm
Location: US (Eastern Time)

Re: [PATCH] Fix export of transformed soft volumes

Postby Christian Walther » Wed Jul 16, 2008 1:54 pm

Nadnerb wrote:A rotation-only matrix is orthogonal

I know that (although I notice that the rest of my linear algebra is getting rusty faster than I'd like it to :)), but is the matrix we get from Object.getMatrix() guaranteed to be rotation-only? In other words, it only stores the rotation and translation, and the scaling is stored elsewhere? I admit I didn't check (although I noticed that it doesn't seem to be possible to shear the object by modifying this matrix), and the documentation doesn't say anything more helpful than "the object matrix".

Edit: I think I see what you're getting at now, but the documentation for Matrix.rotationPart() explicitly states Return the 3d submatrix corresponding to the linear term of the embedded affine transformation in 3d. This matrix represents rotation and scale, which means it's not orthogonal unless the original 4x4 matrix was (which I don't know if it's the case here, as mentioned above). Did you take that into account?

and if you're normalizing the vector in the next line, you don't need to separate out the rotation.

We do have to get rid of the translation, don't we?
Last edited by Christian Walther on Wed Jul 16, 2008 2:04 pm, edited 1 time in total.
Christian Walther
 
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
Location: Switzerland

Re: [PATCH] Fix export of transformed soft volumes

Postby Nadnerb » Wed Jul 16, 2008 2:02 pm

Oh gah, you're right, the translation. :P Anyway, in that case, you just need this, which is still simpler than before. ;)
Code: Select all
Nor = tmatrix.rotationPart() * Blender.Mathutils.Vector(face.no)
Nor.normalize()

The normalize line can be left in case the rotation part function doesn't actually strip the scale. (which is part of the 3x3 matrix)

As to the change I didn't explain in my first post, we shouldn't need to invert the resulting vector (* -1) as multiplying it by the already transposed matrix (unfortunlately left out of the picture before) should accomplish what we're after. You'll have to test that though, as that doesn't seem to make it equivalent to the fix you posted as working.

Edit: you edited while I was posting. Yes I get it. :P
Last edited by Nadnerb on Wed Jul 16, 2008 2:08 pm, edited 1 time in total.
Image
Live KI: 34914 MOULa KI: 23247 Gehn KI: 11588 Available Ages: TunnelDemo3, BoxAge, Odema
Nadnerb
 
Posts: 1057
Joined: Fri Sep 28, 2007 8:01 pm
Location: US (Eastern Time)

Re: [PATCH] Fix export of transformed soft volumes

Postby Christian Walther » Wed Jul 16, 2008 2:08 pm

Oops, we're cross-posting...
Nadnerb wrote:The normalize line can be left in in case the rotation part function doesn't actually strip the scale.

Which it doesn't, as I've edited into the post above.

But, if there is a nonuniform scale in the matix, then we need to do the inverse-transpose.

My last word for today, I'll go to bed now! :lol:
Christian Walther
 
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
Location: Switzerland

Re: [PATCH] Fix export of transformed soft volumes

Postby Paradox » Wed Jul 16, 2008 3:54 pm

Christian Walther wrote:I'll get back to you about the kIsNot flag when I find out what that is and how I check it, but what I can tell you so far is that my visregions work as documented on the AlcScript wiki page - the objects are invisible when the camera is inside the volume. More specifically, the object is visible iff the soft volume field strength at the camera is < 1.0 (whether that is inside or outside depends on the instrength and outstrength values). Whether that is the intended way or not I can't tell.


prp_DrawClasses.py (line 1846). If you remove that line, VisRegions will specify where objects are visible rather than invisible. This line will likely be removed in the next PyPRP release.
Paradox
 
Posts: 1290
Joined: Fri Sep 28, 2007 6:48 pm
Location: Canada

Re: [PATCH] Fix export of transformed soft volumes

Postby Christian Walther » Thu Jul 17, 2008 12:38 am

Nadnerb wrote:
Code: Select all
Nor = tmatrix.rotationPart() * Blender.Mathutils.Vector(face.no)
Nor.normalize()

OK, I've just tried this: In a new, empty Blender document, add a "plane" and go into edit mode. Grab its left two vertices and move them up by 2 units (G-Z-2), so that the face is at a 45° angle. Go to object mode and scale the object by 2 in the Z direction (S-Z-2). Then run the following session in the interactive Python console:
Code: Select all
>>> o = bpy.data.scenes.active.objects.active
>>> o.getMatrix()
[1.000000, 0.000000, 0.000000, 0.000000](matrix [row 0])
[0.000000, 1.000000, 0.000000, 0.000000](matrix [row 1])
[0.000000, 0.000000, 2.000000, 0.000000](matrix [row 2])
[0.000000, 0.000000, 0.000000, 1.000000](matrix [row 3])
>>> n = o.getData(mesh=True).faces[0].no
>>> n
[0.707107, -0.000000, 0.707107](vector)
>>> o.getMatrix().rotationPart() * Blender.Mathutils.Vector(n)
[0.707107, -0.000000, 1.414214](vector)
# wrong normal!
>>> o.getMatrix().rotationPart().invert().transpose() * Blender.Mathutils.Vector(n)
[0.707107, -0.000000, 0.353553](vector)
>>> r = _.normalize()
>>> r
[0.894427, -0.000000, 0.447214](vector)
# correct normal!

q.e.d., the inverse-transpose is needed.

Nadnerb wrote:As to the change I didn't explain in my first post, we shouldn't need to invert the resulting vector (* -1) as multiplying it by the already transposed matrix (unfortunlately left out of the picture before) should accomplish what we're after. You'll have to test that though, as that doesn't seem to make it equivalent to the fix you posted as working.

As far as I can tell, the *-1 is what defines that where the Blender normal points is the inside of the volume. If you leave it away, where the Blender normal points becomes the outside of the volume. I do think that the latter way makes more sense, since outward-pointing normals are the default when you make a new mesh in Blender, but I don't think that we should break everyone's existing soft volumes now by changing that.

Also, Nadnerb, while I have your attention, since you seem to have some experience in this area: Do you have any opinion on whether it's a good idea to transpose the object's matrix in-place instead of operating on a copy, as I've wondered in the first post?
Christian Walther
 
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
Location: Switzerland

Re: [PATCH] Fix export of transformed soft volumes

Postby Christian Walther » Fri Jul 18, 2008 1:26 am

I noticed that the typo I mentioned in this post earlier in this thread, preventing the use of complex soft volume syntax on object visregions, was also present for lamp visregions. This is fixed in r293 in my stable branch. (Developers: the stable branch is what I recommend for inclusion in the trunk. Currently, it contains the three fixes mentioned in this thread. Please review and merge at convenience.)

Paradox wrote:prp_DrawClasses.py (line 1846). If you remove that line, VisRegions will specify where objects are visible rather than invisible. This line will likely be removed in the next PyPRP release.

Right, I can confirm that. If you do remove it, don't forget to also remove it from lamp visregions (prp_LightClasses.py line 400).
Christian Walther
 
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
Location: Switzerland

Re: [PATCH] Fix export of transformed soft volumes

Postby Paradox » Sat Jul 19, 2008 5:41 pm

Something to note about SoftVolumes, PyPRP currently only supports convex regions made up of planes. There are a number of other options, include spheres, bounding boxes, and cones. I'm hoping to look into Bounding Box as a region type in the next release of PyPRP.
Paradox
 
Posts: 1290
Joined: Fri Sep 28, 2007 6:48 pm
Location: Canada

Re: [PATCH] Fix export of transformed soft volumes

Postby Christian Walther » Sun Jul 20, 2008 5:16 am

Interesting. I can see how spheres and cones can be useful, and more efficient than approximating the shape with planes. What's the advantage of using a bounding box though - we can already build boxes out of planes? Do you mean the bounding box of an existing visual object, so that you wouldn't have to define a separate softvolume mesh in Blender?
Christian Walther
 
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
Location: Switzerland

Re: [PATCH] Fix export of transformed soft volumes

Postby Paradox » Sun Jul 20, 2008 5:52 pm

I believe the bounding box Volumes are best suited to cubes. Currently every face of a cubic softvolume is exported individually. Using a Bounding Box Volume, you could save only the bounding box of the cube and produce a smaller object upon export.
Paradox
 
Posts: 1290
Joined: Fri Sep 28, 2007 6:48 pm
Location: Canada

Previous

Return to Plasma Development

Who is online

Users browsing this forum: No registered users and 0 guests