Things a Fan Tool can't manage And Cyan can.

MustardJeep · **Posted:** Wed Sep 09, 2009 5:24 am

Yep time to give the Mod's a nervous twitch. :lol:

PyPrp's Shortcomings

First and best disadvantage; It's a hack, all the wicked cool work is done by plasma. The reason that I am saying this is because I have high hopes for the Cyan sources offering a better way of doing things then are currently available. Dustin elsewhere made mention that learning blender from a blender site and making a Age in blender from that information is "Dangerous" because you could apply techniques in blender that are not compatible with pyprp.

Quote:

It's a little dangerous to learn through sites intended for Blender, as there are many things you can do that won't export. So, people would end up making something, then realise that it won't export, and depending on what they did, they may have to trash all their current work. As Nalates says, you should go to the Guild of Writers.

This brings me to the #2 shortcoming that has haunted Pyprp since day one; Blender is a afterthought. :roll:

Blender offers fully developed systems for creating things like the kemo fireflies, avatar animations, and creating things as wide and varied as puzzles and vehicles. What all of this basically has in common is that it creates something not currently a part of Uru:CC. There is the odd work around to be sure for some individual tasks but by and large you will never see a avatar animation or a puzzle or anything else not of the same "Type" as one already present in Uru:CC. This is something I have always found frustrating that reaching towards the standard tools in Blender seems less important then reaching towards scripts and python.

The Cyan Tool

Okay here are some deductions about the mythic Cyan tool.....

Animations!!!!!
The number one thing that Cyan going open source with plasma means for the common explorer is that it would give the roadmap for making Blender Animation files compatible with Plasma. Funny little creatures can be made, doors can open in new ways, and more then the standard switch/button/lever can move on a machine.

Movies!!!!
Blender has some issues with playing movies in it's own game engine, but Plasma supports it so it should be possible.

The KI!!!
It can be fixed. Even if the KI source is not released having the engine available it is very possible to code a replacement GUI for it that smooths over the worst behavior.

Now for the bad I think is a safe guess for Cyan's toys, Some assembly will be required. A stock server should be feasible within hours of release but to take advantage of Cyan's information will be weeks if not months for each item pyprp could never manage without lots of python working around the issues.

I invite the mods to nuke if they must, but I would rather hope this tempts a discussion or two. but which ever.

veralun · **Posted:** Wed Sep 09, 2009 9:25 am

MustardJeep wrote:

I invite the mods to nuke if they must, but I would rather hope this tempts a discussion or two. but which ever.

I have a question for you:
Why do you want this discussion now and take the risk the mods or Cyan do need to jump in?

Chogon spoke in his post about Hopefully, with a town hall kind of meeting, questions can be answered and a way forward charted.

Chogon wrote:

There are *so* many things we want to do from getting everyone back in the cavern to new fresh ideas. We have had to re-adjust our thinking but the dreams are still alive.

IMO it is better for all of us to wait for this meeting, so we can have a good and constructive discussion here.

AdamJohnso · **Posted:** Wed Sep 09, 2009 10:34 pm

Mustard Jeep, you need to re familiarize yourself with PyPRP as things have changed a bit in the past year. Specifically with the parts about animations and movies...

(In Uru, movies are mostly done with python... It's different in Myst 5+)

Paradox · **Posted:** Wed Sep 09, 2009 11:16 pm

The problem isn't necessarily that the PyPRP developers don't understand things (although there are parts of Plasma that are still a mystery), but often the way Blender and Plasma are designed.

Plasma was written from scratch with 3DS Max as the toolset, even when it was first started by HeadSpin in 1997. Therefore, it often implements things in a way that mirrors or mimics 3DS Max. Especially animations, particle systems, and advanced texturing features are all based on the usual Max workflow.

Blender is an entirely different application, sharing a similar purpose. Think in terms of cars: automatic and standard. Both programs aim to accomplish the same things (and both are quite successful), but they have vastly different internal workings. PyPRP has to work to bridge the gap between Blender and Plasma/Max, and sometimes in areas that Blender falls a bit short PyPRP has to use other methods (AlcScript) to enable certain features.

By far the biggest single feature that Blender doesn't implement is object-based light groups, which are done per-material instead.

EDIT: Err, this post probably sounds defensive for PyPRP... It's not meant to be, it's meant to be a reflection on why some things in PyPRP are as weird as they are.

Robert The Rebuilder · **Posted:** Fri Sep 11, 2009 12:31 pm

MJ - you forgot one more "feature" of Cyan's tool:

Expensive!!!

That's right - like Paradox said above, it is a 3D Studio Max plugin. To be precise, the plugin itself will be free, of course; but the 2009 version of the modeling software by Autodesk can be yours for just $3,100. Note: the version of Max used by Cyan is a couple years old, so you may be able to get that for a cheaper price (~$300).

Not everyone can afford that, but everyone can afford free - which is another reason why Blender was chosen for PyPRP.

Things a Fan Tool can't manage And Cyan can.

Who is online