Previewing Decals for Plasma in Blender

[tikibear]

Jumping through hoops to be able to preview decals in Blender got old really fast. I patched PyPRP to export texture offsets to match Blender's use of texture offsets. Decals are much faster to set up now. I can preview them with the Blender still renderer.

The patch goes in prp_MatClasses.py to plLayer.FromBlenderMTex(...)

# original offset extraction code
uvmobj.LocX = mtex.ofs[0]
uvmobj.LocY = mtex.ofs[1]

# offsets mapped from Blender to Plasma
uvmobj.locX = 0.5 - 0.5 * mtex.size[0] * trickscale + mtex.ofs[0]
uvmobj.locY = 0.5 - 0.5 * mtex.size[1] * trickscale - mtex.ofs[1]

Note that the Y offset is negated.

There are side-effects of this transformation for texture IPOs.

Please let me know if there's a button somewhere that can be pushed instead of patching PyPRP.

[Christian Walther]

Since, wearing my release manager hat, I guess I ought to have an opinion about this , can you explain a few things to improve my understanding?

• Why is it that only you have problems with your textures and apparently nobody else? Is it that you are the only one to use the texture offset/size fields, and everybody else has them at the default 0/1 (where your change makes no difference) and moves their UVs to shift their textures, so they don't notice the problem?
• Would you classify the previous behavior as a bug and the new behavior as correct, or are there any circumstances under which the old behavior is more or equally correct/useful? (I haven't actually tried it myself yet.)
• Is there a reason why you are talking specifically about decals? From a quick glance at the code, it seems to me that the lines in question apply to all textures.

[D'Lanor]

There seems to be some double posting going on but to repeat my concern from the other thread: Will this break the carefully scaled textures in my existing age(s) upon export with this modification? I used offsets many times and I don't feel like redoing everything.

Edit: and what exactly are the side effects for texture animations?

[tikibear]

Thank you all for the great feedback!
If texture offsets and scaling aren't used (ofs=0, scale=1) then there is no effect from this change.
If somebody does make use of offsets and scaling then the offsets (not scaling) would have to be adjusted once the patch was made. The inverse of the patch formula would need to be applied. Assumedly a script could do this to all textures. IPOs would need updates as well, in some cases.
The side effect for animation is that offsets and scales would be coupled. If animation doesn't involve scaling then there's no problem. If it does then the behavior might be different between key frames. Additionally, use of just scaling in an IPO would be a problem since scaling and offsets become coupled. Offsets and scaling together would be needed for an IPO.
If the Z scale is used it scales both X and Y. There is no affect on Blender, so Blender's behavior won't ever match Plasma's in that case.
The patch changes apply to all textures, not just decals.
I have found no way to manipulate the UV map to make Blender and Plasma match. Indeed, the patch matches them regardless of what is done with the UV map.
It seems to me that having textures render differently in Blender vs. Plasma is a bug. But, if nobody else has noticed I would not recommend any changes.
So, it surprises me that nobody else has run into this issue. If I'm the only one who needs the patch I certainly don't propose making it a feature.

[D'Lanor]

It seems to me that having textures render differently in Blender vs. Plasma is a bug. But, if nobody else has noticed I would not recommend any changes.
So, it surprises me that nobody else has run into this issue. If I'm the only one who needs the patch I certainly don't propose making it a feature.

Not that surprising in my case. I never render anything in Blender itself. I have always judged the results of my work only in Uru. When I started with age building I wasted a lot of time trying to make objects look good in Blender, only to find that PyPRP ignored most of that upon export. So I stopped relying on what I see in Blender entirely.
Even with this patch there are still hundreds of properties that a Blender render will show differently than they will end up in Uru. So my question is: why fix only this visual issue and leave the other inconsistencies?

[boblishman]

I agree with D'Lanor... using Blender renders is a dangerous way to build Ages ... Uru has "it's own mind" when it comes to how it's going to display your creations ... and, lets be honest, with the (wonderful) tex_cache, exporting an age can sometimes take less time than a Blender render ! (and at least you can see exactly how it appears in game).
PLease, I beg of you Christian, only "break" my Ages with the next release if you really have to (i.e for some benificial purpose)

[Trylon]

In any case, the trickscale is a dangerous concept.
From my post in the other thread:

At any rate, you should get rid of the trickscale, it can cause trouble when stupid people (read: Trylon) accidentally set z scale in blender to 0.0, and are wondering like crazy why that texture doesn't show up at all.

(Yes, I know I came up with the trickscale idea in the first place, well ... it was a stupid idea )

[Christian Walther]

I just tried this and came to the following conclusions:

• Static case: I agree that the previous behavior is incorrect and the new behavior is correct.
• Animated case: I see no difference at all, and in fact I don't expect any since you didn't modify the plLayerAnimation export. Care to explain?

As to whether the fix should be incorporated - I vote for at least keeping the possibility open. There are other potentially compatibility-breaking features under discussion, and if we decide on including those, I think we might just as well include this one, under two prerequisites:

• There must be a script to convert existing ages. Can you provide such a script, tikibear? I imagine it should be quite trivial.
• Behavior in the static and animated case must match (as far as both are implemented, i.e. for the offset), i.e. you need to fix plLayerAnimation too.

Even with this patch there are still hundreds of properties that a Blender render will show differently than they will end up in Uru. So my question is: why fix only this visual issue and leave the other inconsistencies?

Well, by that argument we'd never get anything fixed. I agree that there is a lot of mismatch in the way PyPRP tries to plumb together Blender and Plasma, most of it by necessity, but I consider that a major source of difficulty in our current age writing process and I think that where the two can be made to match effortlessly, they should.

... and, lets be honest, with the (wonderful) tex_cache, exporting an age can sometimes take less time than a Blender render ! (and at least you can see exactly how it appears in game).

For me, export time isn't the problem, but restarting Uru is. I hope we can get that fixed quickly once we have the source.

PLease, I beg of you Christian, only "break" my Ages with the next release if you really have to (i.e for some benificial purpose)

Hey, no need to beg I'm not the dictator here, I only try to coordinate things. Everyone who cares to voice their opinion is heard. (For that matter, I consider making things less confusing, as this patch does, a beneficial purpose.)

At any rate, you should get rid of the trickscale

Sounds good to me. What was its purpose anyway? As far as I see, it's only an additional scale factor that could just as well be achieved by adjusting the X and Y factors directly? Does anyone use it?

Oh, and one more thing, tikibear:

Note that for the PyPRP devs to incorporate your fix, you should create your own subdirectory in http://svn.guildofwriters.com/pyprp/contrib, then add your modified prp_MatClasses.py file.

Please don't just add the modified file, but copy it from the trunk and then apply the modification, as I describe here. (In a nutshell, it makes it easier to review and merge your work, and uses less storage space on the server. For changes as trivial as this one, it doesn't matter a lot, but it can't hurt to get into the right habits from the start.) If you're not familiar with Subversion, I can help with that.

[Trylon]

At any rate, you should get rid of the trickscale

Sounds good to me. What was its purpose anyway? As far as I see, it's only an additional scale factor that could just as well be achieved by adjusting the X and Y factors directly? Does anyone use it?

It's purpose was to achieve scales higher than the maximum scales blender allows for x and y. (PlasmaXscale = BlenderXscale * BlenderZscale, ... ) Blender caps off the maximum scale at 100 IIRC.
But for those rare situations where you do need them, you're better off just using separate uv maps. The trickscale is just cause of major confusion if accidentally used (it's not very intuitive after all ).

[tikibear]

Indeed I missed plLayerAnimation.FromBlender(...).

I will see if I can derive an acceptable update for plLayerAnimaton.FromBlender(...). If not that scuttles these changes.
I'll make a script to update offsets in materials and IPOs post these changes.
I had no intention of modding anything public myself without knowing how. I'll learn and follow the prescribed process.

Thanks, again, everybody!