PyPRP Discussion: Revised prp_MatClasses.py

[Paradox]

I'm going to echo CW here... If the ambient colour can be handled entirely using the MapTo colour, I think it would be best to use that rather than also having MirCol as an option.

[GPNMilano]

I am confused ... I have lamp flares in Sonavio ... (and they look and behave like Cyan's) ... but by simply using a texture with transparancy ... and setting them as sprites ...
(they don't use ANY vertex colours ...there is no need ...the texture already has the transparency)


I don't understand why the (relatively simple) process of making a lamp flare needs to change (in this example anyway, ... maybe for other things the new class is better ... but I just think this seems complex for a "simple" lamp flare ... )

Sorry for the confusion Bob. You can still do it the old way that you have been (With my mat classes You just need to set the MirCol to black instead of the default white) The reason I use these flags is because I try to match as close as possible to Cyan's stuff. Cyan used a funk ramp multiplying texture for some of their lamp flares. The flags i mentioned were for flares that used a second layer texture. So you can still do it the old way as well. When i extend support for funk ramps (which will be not this release but the next) you'll have the option of your way as well as Cyan's way of two layers for some of the flares. Sorry for the confusion as I was giving an example. Both ways work, mine just matches Cyan's more than the current way.

A second example is for layer animations. Cyan's Nexus stations used two separate objects, One was the stationary ki logo, the other was a glowing ki logo. So to match Cyan's Nexus station logo animations you'd have this:

For the stationary (no glowing) logo you'd have these settings:

In the texture panel you'd select "USEALPHA" for the vertex colors you'd color your logo what ever color you want for your stationary logo. And for the alpha it would be entirely white. (If you're using Cyan's texture for the ki no glow logo) then in the for you material colors you'd set your mat color to white, and the spec and mircol to black for each. You'd also set the ZTransp button and the z-offs to 1. And the passindex would be 1.

For the glowing logo (if you use cyan's texture) you'd match the previous settings except that the colors in the material section would be all black, and the pass index would be 2. You'd also need to create a layer animation similar to cyan's (in this case it would be a 51 frame animation, that animated all color from black to white. The animation would go from 1 to 26 with the animation being black to white and then go to 51 and back to black)

As i said in other threads, the point to all of this is that as OSMO becomes available, and more cavern locations opened up, it's best to match what Cyan did as closely as possible. While I mapped new flags to new settings i kept the old ways as the were. So the only thing that changed was the MirCol setting so that old users and new would have to change as little as possible in their already released ages (if they expand upon them). so you can still set stuff the same way you always did, but also use the new buttons and new flags as well, the only thing that really made a drastic change was the MirCol setting.

As paradox pointed out it would be more ideal to map the ambient color to the mapto section rather than the mircol and than animating it the way i have. (the only reason i did it this way as I said was that at first i set this setting and than didn't realize that the MirCol IPO curves can't be done in blender yet)

[Christian Walther]

Eventually as I expand on the mat classes I'm hoping, if possible, to have all colors and flags set on a per layer basis. But thats a bit down the road as more and more will have to be reworked to make that possible.

So you're planning to change things around more in future relases? I'm not sure if users would appreciate too frequent changes. Could that be a reason to keep the change out of this release and do it all in one fell swoop later?

[Christian Walther]

Hold on - I just experimented a bit and found that I can animate the mirror color just fine in Blender 2.48a (after having had to consult the manual to find out that creating a specific ipo curve works by ctrl-click ). What is your conclusion that the mirror color can't be animated based on - is there anything else about it that makes it unusable for PyPRP? Is it just that it isn't included in any of the default ipo sets from the Insert Keyframe popup menu?

That still leaves the question whether to use the mirror color or the map to color, but I see no reason to use one for the static and the other for the animated case now. The latter has the advantage of being separate per layer, while there is a single mirror color per material. Plus, its pink default value might stand out more when someone forgets to adjust it for a new material.

[GPNMilano]

To put this simply:

As near as I can figure it, (in the case of the ambient color being mapped to the MirCol or "map to" color) the ambient color must be mapped to the MirCol. There is no "get" function for the actual color pallete in the mapto section, at least none that i've found in any of the blender documentation. The reason it works to animate the color is that the pyprp gets the colors for a layer animation from the ipo module. such as "Ipo.MA_texR) for the ambient color. PyPRP grabs the values for each keyframe from the ipo curve not from the actual color pallete. For static colors, pyprp uses the get function like MA.getMirCol.

Since I can't seem to find a "getTexCol" function or anything similar in the blender documentation for the color picker in the map to section, i mapped the static version to the mircol, and the animated version to the ipo curve function like the rest. As christian pointed out there's some difficulty in getting an ipo curve for the mircol, the control of it leaved a lot to be desired. To animate with the MirCol you'd need to first create the IPO curves for each of the individual colors (MirR, MirG, and MirB in the ipo curve window by choosing each one at a time and ctrl+click in the ipo curve window) after which you'd need to select all three and scale x and y them (s+x 0 and s+y 0) to zero. THEN animate them in the color usual way and choosing "available" in the list of choices when you insert the key frame.

To the average user this would be a bit daunting, hence why I chose instead to just use the MirCol as the static ambient color, and animate the color using the col settings in the map to section. If someone could find a more simpler way that would be great as well though.

[Paradox]

You can get the MapTo colour with MTex.col which returns a tuple of RGB.

[GPNMilano]

You can get the MapTo colour with MTex.col which returns a tuple of RGB.

I'll look into setting the ambient color using this information, entirely from the mapto color setting if this is the case.

On an unrelated note:

One of the things that I did not mention in the list of things included with the mat classes is the LayerSDLAnimations. I finally got them working tonight while trying to rework the ambient color animation. They fully export without problems. I originally had issues with them as libPlasma's header for plLayerAnimation's had the SDLAnimation's being a class of the plLayerAnimation, when they actually draw from plLayerAnimationBase. Which is why they weren't on the list originally as I couldn't get them to export correctly. Finally figured out the issue this evening, and so they are working correctly.

The matclasses, by default if the material is animated will export a LayerAnimation. For SDLAnimations, you use the alcscript of:

Code: Select all

visual:
    sdlanim:
        time:

With "time" being the name of the variable in the SDL file. And in that file you put:

Code: Select all

VAR AGETIMEOFDAY "your age name"TimeOfDay[1]

So day and night cycles can now be fully made without the use of prp hacking.

[D'Lanor]

Code: Select all

visual:
    sdlanim:
        time:

With "time" being the name of the variable in the SDL file. And in that file you put:

Code: Select all

VAR AGETIMEOFDAY "your age name"TimeOfDay[1]

Well, done! But I think "time" is a confusing name. Can it be changed to "sdlname"? Or better still, can you make it default to "<your age name>TimeOfDay"?

[GPNMilano]

Code: Select all

visual:
    sdlanim:
        time:

With "time" being the name of the variable in the SDL file. And in that file you put:

Code: Select all

VAR AGETIMEOFDAY "your age name"TimeOfDay[1]

Well, done! But I think "time" is a confusing name. Can it be changed to "sdlname"? Or better still, can you make it default to "<your age name>TimeOfDay"?

I can change it to sdlname. I'm wary about forcing it to default to the age name, as some age names are longer than others, and the name doesn't actually have to be the name of the age, Cyan for instance used NB01TimeOfDay and giraTimeOfDay for the gira day night cycle, and the Hood Clock. So if a writer wants to use a shortened variable name, I'd prefer to give them the option to do so. But changing time sounds like a solid solution, as its less confusing.

[diafero]

I'm wary about forcing it to default to the age name

I think he meant that to be the default.
Like, if you just write:

Code: Select all

    visual:
        sdlanim

it uses "AgeName"TimeOfDay
And if you want a different name, you write:

Code: Select all

    visual:
        sdlanim:
            sdname: bla