[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.
Christian Walther
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
MOULa KI#: 0
Location: Switzerland

[PATCH] Fix export of transformed soft volumes

Post by Christian Walther »

Is this the right place to submit bug fixes for PyPRP?

PyPRP does not correctly export soft volumes that have a rotation or scale - it neglects to apply the transform to the plane normals. This is fixed by the attached patch. For reference, since the forum wouldn't let me attach it unzipped:

Code: Select all

Index: src/prp_VolumeIsect.py
===================================================================
--- src/prp_VolumeIsect.py   (revision 275)
+++ src/prp_VolumeIsect.py   (working copy)
@@ -214,7 +214,8 @@
         for face in obj.data.faces:
             if (len(face.v) > 0):
                 # reversed uru space
-                Nor = Blender.Mathutils.Vector(face.no) * -1
+                Nor = tmatrix.rotationPart().invert().transpose() * Blender.Mathutils.Vector(face.no) * -1
+                Nor.normalize()
                 # transform verts into world space (transposed for uru's reversed space)
                 Pos = tmatrix * Blender.Mathutils.Vector(face.v[0].co.x, face.v[0].co.y, face.v[0].co.z)
                 self.AddPlane(Nor, Pos)


I decided to learn about soft volumes today and ended up spending a few hours trying to figure out why one of my volumes wouldn't work. Even though the forum posts I found mentioned that people usually apply transforms to the mesh data before exporting, I didn't bother checking that on my volume because I was so sure I hadn't rotated it... and of course I was wrong :roll:.

Plus another comment about a few lines above my change (just outside of the context in the patch): Is it safe to transpose the object's matrix in-place, without making a copy first? When I tried that in the interactive Python console, it seemed that the matrix would reset when switching from edit mode back to object mode, but can we rely on that?
Attachments
softvolumetransform.patch.zip
(496 Bytes) Downloaded 309 times
Jojon
Posts: 1116
Joined: Sun Sep 30, 2007 5:49 am

Re: [PATCH] Fix export of transformed soft volumes

Post by Jojon »

Hmm, have you tried using a visregion and seen it working, then?

Is that the sound of Andy opening a bottle of beer for you? :9
Christian Walther
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
MOULa KI#: 0
Location: Switzerland

Re: [PATCH] Fix export of transformed soft volumes

Post by Christian Walther »

Not yet, but I plan to. Stay tuned...

Update: I can make inverted visregions, i.e.

Code: Select all

MyObject:
   visual:
      visregions:
         - "!(MySoftVolume)"
work by making the following change, which seems to be a simple typo:

Code: Select all

Index: src/prp_DrawClasses.py
===================================================================
--- src/prp_DrawClasses.py   (revision 280)
+++ src/prp_DrawClasses.py   (working copy)
@@ -1830,7 +1830,7 @@
         if type(propString) == list:
             for reg in propString:
                 if (reg != None):
-                    if(softVolParser != None and softVolParser.isStringProperty(propString)):
+                    if(softVolParser != None and softVolParser.isStringProperty(str(reg))):
                         volume = softVolParser.parseProperty(str(reg),str(self.Key.name))
                     else:
                         refparser = ScriptRefParser(self.getRoot(),str(self.Key.name),"softvolume")


I'm still trying to figure out why non-inverted regions like

Code: Select all

MyObject:
   visual:
      visregions:
         - MySoftVolume

don't work. The output of the softVolParser for the working inverted case is

Code: Select all

00006421,0000,008C,MyObject
while the output of the ScriptRefParser for the non-working plain case is

Code: Select all

00006421,0000,0088,MySoftVolume
Just sticking the object name instead of the volume name in there (in an attempt of blind trial-and-error :)) doesn't fix things however, probably the object this refers to doesn't exist or something. I'll have to learn more about Plasma and PRP to understand this.
Christian Walther
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
MOULa KI#: 0
Location: Switzerland

Re: [PATCH] Fix export of transformed soft volumes

Post by Christian Walther »

Update 2: Non-inverted visregions work too. That it didn't work for me initially wasn't PyPRP's fault, but was caused by the fact that my soft volume had an instrength of 0.8. The behavior of a visregion seems to be defined as make the object visible iff the soft volume field strength at the camera is < 1.0, so with an instrength of 0.8 (and the default outstrength of 0.0) the object was always visible, while in the inverted case, with field strength varying between 0.2 and 1.0, visibility did switch.

This also works with the unmodified PyPRP 1.5 though (provided that the object defining the soft volume has no transform), so Andy's problem must have been something different.
User avatar
Lontahv
Councilor of Artistic Direction
Posts: 1331
Joined: Wed Oct 03, 2007 2:09 pm

Re: [PATCH] Fix export of transformed soft volumes

Post by Lontahv »

:shock:

So many people that are fixing their own pyprp bugs. :D

Thanks for working to get it working rather than complaining about the problem. 8-)
Currently getting some ink on my hands over at the Guild Of Ink-Makers (PyPRP2).
Christian Walther
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
MOULa KI#: 0
Location: Switzerland

Re: [PATCH] Fix export of transformed soft volumes

Post by Christian Walther »

:D /shrug - figuring out stuff on my own is usually faster, not to mention more fun, than writing up a good question and waiting for someone to answer it, and by the time I've got enough information to make an educated complaint (and to know it's not me who is doing something wrong), trying to fix things myself tends to be more efficient than waiting for others to fix it for me. The great thing about open-source software is that it allows me to do that. :geek:
D'Lanor
Posts: 1980
Joined: Sat Sep 29, 2007 4:24 am

Re: [PATCH] Fix export of transformed soft volumes

Post by D'Lanor »

My idea exactly. :D btw, you can grab yourself an SVN client and add your fix to the contrib section if you want.
"It is in self-limitation that a master first shows himself." - Goethe
Christian Walther
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
MOULa KI#: 0
Location: Switzerland

Re: [PATCH] Fix export of transformed soft volumes

Post by Christian Walther »

Oh, it didn't occur to me that there could be public write access there (even though I noticed the empty user names in the revision log). Thanks for pointing that out. The two changes posted in this thread are now in http://svn.guildofwriters.com/pyprp/contrib/CWalther/stable as r284 and r285. (Plus a few others, including the export-with-modifiers-applied from the How to make flat faces/sharp edges? thread, in http://svn.guildofwriters.com/pyprp/contrib/CWalther/experimental.)
Paradox
Posts: 1295
Joined: Fri Sep 28, 2007 6:48 pm
Location: Canada
Contact:

Re: [PATCH] Fix export of transformed soft volumes

Post by Paradox »

There is/was a bug with Visregions where the kIsNot flag was set by the DrawInterface. I believe that this has been fixed in 1.5, but the result was that all visregions with kIsNot set behave opposite as intended.
Christian Walther
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
MOULa KI#: 0
Location: Switzerland

Re: [PATCH] Fix export of transformed soft volumes

Post by Christian Walther »

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.
Post Reply

Return to “Plasma Development”