Previewing Decals for Plasma in Blender

[D'Lanor]

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?

Fine by me if it does all that is advertised. Is there a version ready to be tested?

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.

That is an argument which can easily be reversed. If a contribution is accepted without my agreement it would be me developing a branch of my own.

[boblishman]

Fine by me if it does all that is advertised.

me too ... I have no problems if we know in advance that things are going to be "broken" ... and that there is a "fix" (or at least some documentation on how to fix existing projects) ... progress is always a bumpy ride ...

[tikibear]

I'll see if there's some kind of renormalization that can be applied, automatically, if the first mapping pass moves values outside the accepted ranges.

[tikibear]

Oh, duh, if I scroll down I can see you've already come up with a fix. I'll check it out. Thanks!

[tikibear]

It looks as though the "% 1.0" mod fixes the offset overflow issue for repeated textures. The mod disables offsets for decal alignment. Decal alignment is the motivation for the change in the first place. If nobody else uses offsets for that purpose then that's not an issue. There are, of course, other ways of making decals.

BTW is the animated texture scaling I put in a boon? I put a demo in Paper Pagodas. I haven't thought of much to do with the feature.

[Christian Walther]

Is there a version ready to be tested?

Yes, just drop http://svn.guildofwriters.com/pyprp/contrib/tikibear/src/prp_MatClasses.py into your trunk checkout (if it's at r404 or newer), or

Code: Select all

svn merge http://svn.guildofwriters.com/pyprp/contrib/tikibear/src/prp_MatClasses.py trunk/src/prp_MatClasses.py

To use the conversion script prototypes forBlender.py and forPlasma.py, load them into a Blender text editor window and use Text > Run Python Script.

That is an argument which can easily be reversed. If a contribution is accepted without my agreement it would be me developing a branch of my own.

Point taken. In all seriousness though, I'd still prefer that scenario to mine because it would mean that the general release- or trunk-using public would get the contribution. I'd rather risk pushing a controversial change out to the users (if they don't like it, they'll complain and it can be backed out) than have them miss out on a potentially useful one.

It looks as though the "% 1.0" mod fixes the offset overflow issue for repeated textures. The mod disables offsets for decal alignment. Decal alignment is the motivation for the change in the first place.

Ah, good point. I didn't think of non-repeating textures. Hmm, that means that there would be situations that can be achieved using the old PyPRP but not using the new one. In other words, the automatic conversion isn't as complete and reversible as I advertised above. I wonder if such situations occur in practice. I guess finding out is what I'm planning to do a beta release for...

The best solution would probably be to use something like math.fmod(x, 10) instead of x % 1.0 for the offset, have you already tried that? (apparently, fmod preserves the sign of x, % doesn't)

BTW is the animated texture scaling I put in a boon?

Sure! I actually wondered why it wasn't there when I had my first look. It just seemed like a missing piece. Personally I don't have any use for it at the moment, but that doesn't mean a lot, as I'm not a great Writer.

[tikibear]

I'm thinking that the modulo operation applies to loading Plasma from Blender, NOT updating the Blender file. That way it doesn't interfere with the reversibility of updating the Blender file.

Out-of-range offsets for decals can't be fixed by a modulo operation because decals aren't repeated.

I think the possible scenarios are:

a) offsets are in-range

b) offsets are out-of-range and the texture repeats

c) offsets are OOR and the texture is a decal

Situation (b) is correctable by a modulo 1.0 operation. Situation (c) cannot be fixed and should be reported as offset use beyond Plasma's limits. So, maybe the solution is to check for repetition and perform the modulo operation for an OOR repeated texture. For an OOR decal texture fail with an error OR perform the modulo operation and generate a warning that the texture will be misaligned because offsets are out-of-range. I like the warning approach, but it would mean reading through the log to see the warning. Maybe it's better for the Blender-to-Plasma script to fail if it can't do what you want.

The bottom line is that decal alignment by offsets has limitations in Plasma.

[Christian Walther]

I'm thinking that the modulo operation applies to loading Plasma from Blender, NOT updating the Blender file. That way it doesn't interfere with the reversibility of updating the Blender file.

Er - what? Now you're confusing me again. Probably in the same way your script names confuse me. Can you explain in different terms?

So, maybe the solution is to check for repetition and perform the modulo operation for an OOR repeated texture. For an OOR decal texture fail with an error OR perform the modulo operation and generate a warning that the texture will be misaligned because offsets are out-of-range.

Sounds good to me.

I like the warning approach, but it would mean reading through the log to see the warning.

We can show the warning/error in the GUI for the conversion script. It should display a summary of what it did anyway. I haven't planned in detail yet how to do that. I'd like to do it the same way for all conversion scripts (assuming that more of them will come).

The bottom line is that decal alignment by offsets has limitations in Plasma.

Plasma has no limits, as far as I'm aware. (As shown by the fact that the ages exported with the current PyPRP work.) The limits we're running into here are Blender's.

[tikibear]

Oh, dear! I'm the one who's confused. Indeed it's the conversion for Blender that has the limitations.

I don't like the idea of a conversion that isn't reversible, either. Maybe a third script is called for.

The existing conversion script can be modified to check for overflow before it changes anything. If an overflow would occur the script can stop and report that without making any changes. The script can report which textures can be normalized (repeated textures) and which can't (decals).

A separate script could be created that will convert and normalize textures and warn that it has done so. I think we'd need a normalized reverse conversion script, too. We still end up with conversions that can't be, strictly, reversed, but at least the user can be warned and make a backup before actually performing the conversion.

I'm concerned that this is becoming too complicated. Though, if nobody else uses decals the normalized changes should be fine.

[Christian Walther]

I'm not sure what the use is of a script that warns about an overflow before it changes anything. What is the user to do in that case? Continue to use PyPRP 1.5? Neither the unconverted nor the lossily converted texture will export the way it used to in PyPRP 1.5, there is just no way to place his decal identically in PyPRP 2.0, using only the texture offsets. He will have to make a separate UV layer. We could automate that, but I don't think that's worth the trouble - that's where things would become too complicated.

I wouldn't worry about this too much. At the moment I still work under the assumption that out-of-range decal placements are rare, even among the people who do use the texture offsets to place their decals. We're not making the range of achievable decal placements smaller, after all, just different. Beta testing will show if that's not the case, and then we can start worrying.