Previewing Decals for Plasma in Blender

[diafero]

I'm afraid I can't help you with ULM problems, but you could email it to Old Wolle, Dustin or me (diafero a-t arcor d-o-t de) and we will put it on UAM. If the age is too big to attach, just put it on some webspace or a free upload website and send us the link.

[Christian Walther]

OK. I've used Clearcase, which has similar behavior. I've done my share of merging files.

Does that mean you don't need any more help with Subversion? I'm still available, of course. I have no experience with Clearcase, so I couldn't tell you about parallels and differences to Subversion.

BTW, isn't the plugin source, that's going to be released, for PhysX rather than Plasma?

I think you're confusing a few things here. The plugin that Cyan is going to release the source for is for 3D Studio Max (or for Plasma, depending on which way around you interpret "for" - it exports from 3DSMax to Plasma). It has absolutely nothing to do with PyPRP or Blender (other than being a competing product, so to speak), so I'm not sure what the relation to the topic of this thread is. The expression "PhysX rather than Plasma" does not make any sense to me, the two things are not alternatives. PhysX (the physics library) is used by Plasma (the game engine that Uru runs on). By the MOUL version of Plasma, which we will be getting the source of, to be exact - previous versions used Havok, and the Myst V version used ODE. In the future, we may attempt to replace PhysX by an open-source library.

[tikibear]

The mysterious ULM glitch has gone. Cue eerie music.
I think I'll be able to navigate Subversion for a while, thanks to all your help!
You have answered my question about the we-hope-soon-to-be-released plugin. I figured I was just behind the curve on that one.

[tikibear]

I think I've copied, modded and committed prp_MatClasses.py to contrib/tikibear. Please let me know if it looks as though I've pressed all the right buttons.

[diafero]

Your first commit (407) put a lot of strange files into the repository, that does not look right. The two others look fine for me though.

[Christian Walther]

Yes, revision 408 (and 409) is perfect! In revision 407, it looks like you added an entire new (empty) repository in addition to creating the /contrib/tikibear/src folder (which was probably all you wanted). These files and folders (README.txt, conf, db, format, hooks, locks) are useless, you can get rid of them using TortoiseSVN > Delete in your working copy or in the repository browser (or svn delete on the command line).

You can't nest repositories (from the point of view of the "outer" repository, the "inner" one is just a bunch of files) - to create a folder, just create it in the usual way in your working copy, then svn add it and it will be added in the next commit, or create it directly in the repository (context menu > Create Folder in the repo browser in Tortoise, svn mkdir <URL> on the command line).

[tikibear]

I'm still not clear on setup. I think I got rid of the extraneous files.
I forgot, earlier, to add the scripts that update the offsets in Blender projects. "forBlender" sets the offsets for use once the PyPRP update is installed. "forPlasma" reverts offsets if the PyPRP changes are backed-out. These aren't great names. Please let me know of better names.

[Christian Walther]

I'm still not clear on setup. I think I got rid of the extraneous files.

Looks good. If you had deleted the files in your working copy instead of directly in the repository, you could have done it in one commit instead of 6, but there's nothing wrong with that, it just makes the log a bit longer to read. If you have any specific questions, feel free to ask.

I forgot, earlier, to add the scripts that update the offsets in Blender projects. "forBlender" sets the offsets for use once the PyPRP update is installed. "forPlasma" reverts offsets if the PyPRP changes are backed-out. These aren't great names. Please let me know of better names.

I wouldn't worry about this too much, as we probably won't keep these as stand-alone scripts, but integrate them into prp_Wizards.py, along with possible other conversion scripts. I'd have called them something like "PyPRP 1.5 to 2.0" and "PyPRP 2.0 to 1.5" (assuming this will end up in the release and we'll consequently call it "2.0"). To me, "forBlender" and "forPlasma" don't make it clear at all which is which - since PyPRP is the connecting piece between Blender and Plasma, aren't both equally for Blender and for Plasma?

[Christian Walther]

I have tested this and found one little problem: with textures with high scale factors, such as the detail layers from the Getting Started with Writing tutorial, I get this error:

Code: Select all

Traceback (most recent call last):
  File "forPlasma.py", line 37, in <module>
ValueError: values must be in range [-    10,    10]

To fix this, I propose the following change:

Code: Select all

Index: contrib/tikibear/src/forBlender.py
===================================================================
--- contrib/tikibear/src/forBlender.py   (revision 416)
+++ contrib/tikibear/src/forBlender.py   (working copy)
@@ -34,7 +34,7 @@
          
          nChannels += 1
          
-         mtex.ofs = (mtex.ofs[0] + 0.5 * mtex.size[0] - 0.5, -(mtex.ofs[1] + 0.5 * mtex.size[1] - 0.5), 0.0)
+         mtex.ofs = ((mtex.ofs[0] + 0.5 * mtex.size[0] - 0.5) % 1.0, (-(mtex.ofs[1] + 0.5 * mtex.size[1] - 0.5)) % 1.0, 0.0)
          
          # for the IPO
          #
Index: contrib/tikibear/src/forPlasma.py
===================================================================
--- contrib/tikibear/src/forPlasma.py   (revision 416)
+++ contrib/tikibear/src/forPlasma.py   (working copy)
@@ -34,7 +34,7 @@
          
          nChannels += 1
          
-         mtex.ofs = (mtex.ofs[0] - 0.5 * mtex.size[0] + 0.5, -mtex.ofs[1] - 0.5 * mtex.size[1] + 0.5, 0.0)
+         mtex.ofs = ((mtex.ofs[0] - 0.5 * mtex.size[0] + 0.5) % 1.0, (-mtex.ofs[1] - 0.5 * mtex.size[1] + 0.5) % 1.0, 0.0)
          
          # for the IPO
          #


Tikibear, can you check this?

Apart from that, everything appears to work fine, both with static and animated textures.

[Christian Walther]

If tikibear is MIA (nothing wrong with that), I'll take responsibility for my proposed fix to the conversion scripts.

To resume the discussion about whether this should be included in the release: D'Lanor, Bob, or anyone else who had concerns about the compatibility-breaking nature of this, would you accept it given that there is a simple, automatic, complete, and reversible option to convert existing ages?

Apart from my opinion that it is a sufficient improvement for new projects (or continued work on existing projects) to justify a certain one-time inconvenience for existing projects, I think you also need to take into consideration that the more contributions you decline, the more you encourage the contributor to continue to use and develop their own branch, in the worst case to the point of sufficient divergence from the trunk to eliminate all chances of ever having any of their contributions merged back into the trunk and made useful for the greater public.