Is it time for a new PyPRP release?

[D'Lanor]

Thanks. The multiplier is there because currently lights need to be insanely bright to cast a decent shadow. And my age does not come with sunglasses.

There is an old post from Christian about it somewhere. To calculate the energy a * 2 multiplier is used. Consequently it should use the same multiplier to calculate the shadow strength.

You can remove the multiplier if you don't like it. The other fix in my lightclasses is essential I can assure you.

[Nadnerb]

I noticed that... Very interesting.. I wonder if that's why I've never been able to run any ages exported as uu from pyprp...

*test*

Omg! You fixed it! I can export ages to UU now!

*merge*

I left the shadow change in, but made a note of it in the svn log.

[Christian Walther]

At this point, if you want to take up the "release" job, you'll basically need to do three things.

• Find out what's new by scanning the SVN logs for anything that looks new or interesting, and then come by IRC and ask questions until you understand how to use a particular feature, and then create a step by step tutorial through creating an age that uses that feature on the wiki. Wash, rinse, repeat until anything you consider necessary to the release is documented.

...
You may notice that this layout shifts most of the work to you. I am assuming because you have publicly volunteered to do this, that you are in fact, willing to do all of it, and I'm mainly posting just to assure you that you won't be stepping on any toes.

Well, I certainly won't have time to do that. I'm offering my help with organizing this, not with doing all the work myself.

If it's just you who feels unable to get his own additions documented (and I respect that, of course - nobody owes anything to anyone here), then I guess we can deal with that (I haven't checked in detail yet what they are - I seem to recall that many of your commits were merges on behalf of other contributors). But if the majority of developers feels like this, then I see little chance of getting this off the ground.

So far, we seem to have support from D'Lanor, GPNMilano, Hoikas, and myself; no support from Nadnerb; no clear vote from Lontahv; and no sighting of Paradox and Robert the Rebuilder. Have I got that right? Plus a few non-developer volunteers willing to write documentation with help from the devs. (That list of names, by the way, just comes from a cursory sift through the SVN log. I don't know in detail who of you actually has how many features ready for release, and how many of them are major enough to need documentation.)

I'm not sure a "beta" release will work well, as the maximum total userbase of pyprp is small enough that you'd need to put out a global announcement to get testers anyway.

I was thinking of contacting everyone who has published an age so far. At least the ones who are registered on this forum and reachable by PM, which I assume is the majority. I assume there should be at least a few among them interested in and available for testing.

I seem to recall that there was a bit of an uproar after the 1.5 release because it broke people's ages (partly by design and partly due to bugs). That's what I'd like to avoid by issuing a beta.

I think what's needed most is a good solid and united piece of detailed documentation. It should be along the lines of a Linux manual file (rather large, long, and in one piece). Sort of like this: http://www.phpbb.com/support/documentation/2.0/

That's a laudable goal, but it seems a bit overambitious to me. I fear we won't get a release out in time if we set ourselves such goals. For this release, I think we should stick to preparing a bunch of disjointed wiki articles.

There is an old post from Christian about it somewhere. To calculate the energy a * 2 multiplier is used. Consequently it should use the same multiplier to calculate the shadow strength.

Not a post but a commit message:

Code: Select all

------------------------------------------------------------------------
r287 | (no author) | 2008-07-16 18:47:15 +0200 (Wed, 16 Jul 2008) | 1 line
Changed paths:
   M /contrib/CWalther/experimental/src/prp_LightClasses.py

I'm not sure why lamp energy is being multiplied by 2 for the diffuse and specular colors, but as long as it is, I think that should be done for the ShadowMaster too, otherwise shadows come out pretty weak for a full-white lamp of energy 0.5.
------------------------------------------------------------------------

(I never intended that to be merged into the trunk because it changes existing ages, but if you think it's worth it, all the better.)

[Paradox]

If the goal is to never break compatibility with existing Ages, then development might as well stop right now. There is no way to add more features to the plugin without shifting things around a bit and requiring people to do things differently.

This is the number one reason why everyone has been so hesitant to develop anything or merge anything from the contrib folders.

[Trylon]

I'm in too btw. If we're all going to do some work on pyprp again, I'm game too.

About compatibility breaking:
That's why we came up with versions back in v1.0.0, it was to have some slack in having or breaking compatibility.
GoW Pyprp 1.0.0 itself was a huge break with existing stuff, that's why we put out a legacy release (0.5) of the previous version./

I'd say that if new functions are going to break functionality, we should just shove backwards compatibility aside and work together on the GoW Pyprp 2.0.0 release
(major compatibility breaking releases get a new major version number in our numbering scheme)

Note:
The Gow Pyprp versioning scheme is
[compatiblity level].[new functionality].[bugfixes]

[Christian Walther]

I'm in too btw. If we're all going to do some work on pyprp again, I'm game too.

Great. You just didn't figure on my list because I see no commits referencing your name in SVN. In what area would you see your contributions to a release? Your plan posted earlier suggests management (which would mean I wouldn't have to )?

I'd say that if new functions are going to break functionality, we should just shove backwards compatibility aside and work together on the GoW Pyprp 2.0.0 release
(major compatibility breaking releases get a new major version number in our numbering scheme)

The only problem I see with that is that people might confuse it with the libPlasma-based PyPRP 2.

I don't know if there is anything majorly compatibility breaking in store right now. Anyone? GPN's stuff maybe? I doubt the shadow amplification qualifies as major, and my other two features (modifier application and normal recomputation) don't break anything. I was working under the assumption that the release would be called 1.6 up to now, but that's a detail.

[Trylon]

Great. You just didn't figure on my list because I see no commits referencing your name in SVN. In what area would you see your contributions to a release? Your plan posted earlier suggests management (which would mean I wouldn't have to )?

My past contributions to GoW Pyprp 1.0 included Alcscript, rewrite of all the base classes (Physical, drawable, material, camera, light) and a few other things. At the moment I've got nothing done but if needed I think I could pick up anything.

The only problem I see with that is that people might confuse it with the libPlasma-based PyPRP 2.

I don't know if there is anything majorly compatibility breaking in store right now. Anyone? GPN's stuff maybe? I doubt the shadow amplification qualifies as major, and my other two features (modifier application and normal recomputation) don't break anything. I was working under the assumption that the release would be called 1.6 up to now, but that's a detail.

Well, from what I hear, that libplasma based pyprp isn't out of the concept state yet, so as far as I'm concerned, they'll just have to invent a new name for it

[Marcello]

I would like to add my support to Paradox' view on compatibility with older plugins. For progressions sake we will have to sacrifice compatibility every so many releases.

[Paradox]

Something that I think people might want to develop for the next version of PyPRP are fake clusters.

In my contrib, I have support for real clusters (using plClusterGroup and a number of other classes) from some work by Lontahv. Unfortunately, real clusters are quite limiting, don't support shading or lamps, and are difficult to work with.

Recently I discovered a better way to implement "fake" clusters: Export each Blender Mesh as a buffer group in DrawableSpans. Each Blender object as a plIcicle. Multiple Icicles can reference the same buffer data, making "fake" clusters that have all the advantages of being regular geometry. Only thing that must be noted is that the mesh data must be exported in local space, and then transformed using the matrices in the Icicles.

I would implement this myself in my contrib, but I'm still quite lost when it comes to getting data into the DrawableSpans (it goes in one function, and comes out another... no idea what happens inside ). This would be a slight improvement for Ages that re-use a lot of geometry by cutting down on the amount of sotred vertex data, and requiring the mesh to loaded into memory only once, rather than for each instance of the object.

[Trylon]

I might be able to help with that....