Page 1 of 3

Shell 126

PostPosted: Sun Mar 21, 2010 7:30 am
by Egon
So, I'm middling (again) with Blender + PyPRP for over a week now, made a couple of things for my shells (like first objects, Journal, etc.), so it's time to get serious.
I'm starting to implementing my idea for a 126 shell, which will be a garden "a like", and I figured that I might as well stream some updates of the work.

First: there will be a "water paths", starting from "waterfallchimney"TM :), which I made today:
waterchimney.jpg
waterchimney.jpg (62.03 KiB) Viewed 9461 times

Thanks to tutorials gathered on GoWiki, this waterfall is now having sound, and moving texture simulating falling water.
Few toughs here: dam, 3D modeling is hard. As you can see geometry of this model isn't very complex, yet aligning all vertexes and proper UV editing did took me more time than I expected.

Question:
I have textured model, with PNG texture, which has alpha channel. Although I did "uncheck" "UseAlpha" button in "Texture buttons", after exporting object is still being transparent in the game. Does PyPRP ignores this button?

Quickupdate:
I manage to make prototype of a bench:
bench.jpg
bench.jpg (20.46 KiB) Viewed 9446 times

Again: making a simple thing full of 90 degree angles is a snap. Making something organic is lots of time. I still don't like result: texture is to dark, and some angles are to sharp.

Next update soon.

Re: Shell 126

PostPosted: Wed Mar 24, 2010 9:38 am
by Robert The Rebuilder
Thanks for sharing your images, Egon - that's a terrific start for a first-time age writer!

Regarding your question: PyPRP will scan the PNG file to determine if it has any alpha and will internally set alpha rendering flags, regardless of the UseAlpha button. So, I'd recommend removing the alpha channel from the texture.

More notes on transparency handling in PyPRP can be found here.

Re: Shell 126

PostPosted: Sun Apr 04, 2010 11:08 am
by Egon
Another item added to shell, and it was a tough one (I will not show screenshoots because this object without movement isn't looking good ;) ).
But I want to share with some problem:

Exporting IPO Curves works, yeah :)
Exporting parenting of objects also works, yeah :)
Exporting IPO Curves of child object does not work, noo :(

What I'm talking about?
Imagine a car, which You animate to move forward with IPO curves (simple LocX curve).
Now imagine that there is a steering wheel which You animate with another IPO curves to rotate (simple RotZ curve).
Now imagine that this wheel is a child of a car in Blender.

Thanks to that, when car is moving, wheel moves with a car, and spins around Z axis.

The thing is, then I try to export with such object, the produced Age, make Uru:CC crash.

Do You know what I might do wrong, or maybe some workaround to produce effect described above in another way?

Re: Shell 126

PostPosted: Sun Apr 04, 2010 11:12 am
by Agenotfound
Egon wrote:, or maybe some workaround to produce effect described above in another way?


This won't probably help you as you are using blender but the Max plugin offers the option to create a complete vehicle for Uru. ( you model it then define what are the wheels, chassis, etc.. but I haven't tested it yet.)

Re: Shell 126

PostPosted: Sun Apr 04, 2010 1:23 pm
by diafero
This won't probably help you as you are using blender but the Max plugin offers the option to create a complete vehicle for Uru. ( you model it then define what are the wheels, chassis, etc.. but I haven't tested it yet.)
I bet this is for Zandi's truck?

On topic: There's one bell ringing here related to "animation" and "crash"... did you check that "Actor" button in Blender (not sure where is is)?

Re: Shell 126

PostPosted: Sun Apr 04, 2010 1:24 pm
by Jojon
I'll risk a guess that you have forgotten to give the "steering wheel" object a coordinate interface (though ticking its scripts/actor button). You'll need to have a coordinate interface for EVERY animated object - it is not inherited.

EDIT: The ninja's lightning speed got him in before me... :)

Re: Shell 126

PostPosted: Sun Apr 04, 2010 1:35 pm
by Egon
diafero wrote:On topic: There's one bell ringing here related to "animation" and "crash"... did you check that "Actor" button in Blender (not sure where is is)?


Well, I was having problems with some of my child objects, which where not moving, and it toured out they didn't have "Actor" set on, so your suggestion might be the case. Ass soon as I test I will let know.

Jojon wrote:I'll risk a guess that you have forgotten to give the "steering wheel" object a coordinate interface (though ticking its scripts/actor button). You'll need to have a coordinate interface for EVERY animated object - it is not inherited.

coordinate interface - I have no idea that are You talking to me ;)

EDIT: Yeap, that was it: I didn't set Actor on for child object.
Another question: does IPO Curves need to have ad-least 4 points? I wasn't able to export age, because I was getting "Divide be Zero" error (in export_curve function), but adding 4 point to curve helped.

Re: Shell 126

PostPosted: Wed Apr 07, 2010 2:32 pm
by Jojon
Don't think that should matter - two should be quite enough, I am, however, pretty sure any double keys (more than one point on the same frame ) would throw you that error...

Re: Shell 126

PostPosted: Thu Apr 08, 2010 1:09 am
by Egon
Jojon wrote:Don't think that should matter - two should be quite enough, I am, however, pretty sure any double keys (more than one point on the same frame ) would throw you that error...


How is this possible? I though that if I do insert Key for example "Loc", in the frame that already has a key for a Loc, for a particular object, Blender just overwrites existing Key with the new one?

Re: Shell 126

PostPosted: Thu Apr 08, 2010 3:06 pm
by Jojon
Yep, you are perfectly right - inserting a point at a frame that has one already, will modify the old one, rather than adding a new.

However; if you begin to edit the curves manually, using the IPO curve editor (which, by the sound of it, you have yet to do), you are perfectly able to create point duplicates and even have them on the exact same spot, which would cause a division by zero - it is even possible (but you don't want to do that) to place points on fractions of frame numbers, not just integers, so it is perfectly possible to place a point on frame 1.5, or frame 12.3456.
(holding down ctrl, while moving a point, will make movements in discrete, full frame steps, much like in other editing panels (NB: that does not mean it snaps to integers. Ctrl-grab from frame 1.5 and the next one will be 2.5 -- not 2.0))

If your animations need a degree of precision, you may find yourself more or less forced to use the curve editor, to avoid strange overshoots and such.
In order to make the in game animation properly correspond to what you see in Blender, your curve weight handles should be spaced equidistant between every pair of neighbouring points, on the X (time) axis (remember that you can use the X and Y keys, to restric movement to a single axis, just like in other editing panels).
While dabbling with this anyway, you'd do well to set all handles to "free" mode, as well. This lets you place the "in" and "out" handles for the points individually, as opposed to having them connected, like the ends of a seesaw and this means you can make sharp corners on the curve.