Page 2 of 3

Re: Shell 126

PostPosted: Thu Apr 08, 2010 10:45 pm
by Egon
Jojon wrote: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

Aaahh, I see.
BTW: I already did used IPO Curve Editor quite a lot actually :)-
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.

Since I did lot of editing, and I probably have some point on fractions of frames I'm afraid to ask: But WHY I don't want do do that? Have I understood correctly that my animation might be a little different from what I see in Blender?

Re: Shell 126

PostPosted: Tue Apr 13, 2010 11:30 am
by Jojon
Well, I don't KNOW that, just guessing -- our developers would know better, but I've never asked that, specifically :) (gotta ration disturbing them, lest they lop one's head off ;).
I've gotten it into my head that Plasma lists keys at frames enumerated using integers, replayed at a fixed rate of 30fps. (somewhat speaking against this, we have the fact that we define our loops using times, rather than frames and PlasmaShop will show markers within animations as times, as well -- sooo, the 30fps thing may well just be a pyPRP convention, to give us something of a least common denominator amongst builders.)

Anyway, IF this is the case, pyPRP would be rounding any non-integer frame number while exporting, again possibly throwing a division by zero.


The important bit, with regards to having the animation look the same in Blender and in URU, would be the equidistant spline handles thing; I had some terrible overshoots and bad synchronisation, until Christan Walther straightened me out on that. :)
(Hmm, gotta research writing a script that does that automagically, for all selected curves, one of these days - would save tons of fiddling...)

Re: Shell 126

PostPosted: Sat May 01, 2010 5:15 am
by Egon
Meanwhile in the land of "Egon is trying to enjoy his hobby despite cyan shadow in horizon"TM....

So up today I got footsteps sounds working (no more grass on water :)), and successfully digged canals in Shell floor (not as easy as I though).

I also tryed some very standard feature of Blender: "Linking".
Instead of Appending object from another blend file, I just linked it, and then use "Add/Group/Object name".

And it's working. But only in Blender. After exporting shell, and testing in uru the object don't exists.

Some PyPRP glinch?

P.S. Yes, I checked page_num and it's not an issue.

Re: Shell 126

PostPosted: Sat May 01, 2010 6:59 am
by tachzusamm
I tried to use linking objects instead of importing them too a while ago, with no luck.
My guess is that PyPRP just does not evaluate linked objects, but it would be really nice if this could be done.

Re: Shell 126

PostPosted: Sat May 01, 2010 10:34 am
by D'Lanor
PyPRP exports all objects in the current scene. So if linked objects would not become part of the current scene (which was my first hunch) they are ignored. However I just tried this and Blender did add the linked object to the current scene (with a small [Li] icon). And it also exported fine. :?

So what you may want to check in the outliner is whether your linked object is listed in your current scene.

Re: Shell 126

PostPosted: Sat May 01, 2010 11:29 am
by tachzusamm
Hm, I checked and tried this again now; the object group did not export, although it is attached to the scene and visible in the outliner.
Maybe the problem is not that it is a linked object, but that it is a group.
By the way, it is visible in the 3D view as well, although I cannot select anything else than Object Mode - which is normal for groups, I assumed.

But there are options in the outliner for the object:
- Unlink ( useless here )
- Make Local ( which seems to change nothing )
- Link Group Objects to Scene ( which splits the group, which will let us get rid of the advantages of grouping / linking )

EDIT: Yes, it gets exported when the group is split after the "import" (linking) - but some objects of the group are located somewhere else in URU than shown in the 3D view.
Weird.

Re: Shell 126

PostPosted: Sun May 02, 2010 7:25 am
by Egon
Well yes, I did link "group" instead of object or mesh from external file.
Blender Artist do this way: more things are being linked this way (for example if an object got modifiers, only linking group will carry them other).

Netherless: I didn't get it working the way I wanted so I used a work around:
I don't use external files, I got my main prop model directly in shell file but in a place in which is not visible (actually in case of Shell it's not even exported to shell PRP page). And instead of duplicating it (Shift+D) I use linked duplicate (Alt+D).
This way I crate new objects, but they share topology.

Re: Shell 126

PostPosted: Tue May 18, 2010 10:47 pm
by Egon
Meanwhile in The Alliance of Independent Writers base (codename "Shell 126") work on developing new secret weapon of mass destruction continues...

Ok, so I have some problems with wavesets.
When I stand next to them, they look terrible:
closeup.jpg
closeup.jpg (43.1 KiB) Viewed 8321 times


But if I stand far enough, and at the right angle, they look close to that I want them to look.
faraway.jpg
faraway.jpg (53.93 KiB) Viewed 8321 times


My current waveset setting are:
Code: Select all
s126RiversWaveset:
    type: waveset
    visual:
        waveset:
            geostate:
                maxlen: 6.25
                minlen: 6.0
                ampoverlen: 0.001
                chop: 0.0
                angledev: 1
            texstate:
                maxlen: 6.25
                minlen: 0.78
                ampoverlen: 0.01
                chop: 0.5
                angledev: 1
            ripplescale: 100
            specnoise: 0.5
            specstart: 250
            specend: 1000
            depthrange:
                opac:
                    start: 0
                    end: 0.5
                refl:
                    start: 0
                    end: 1
                wave:
                    start: 0
                    end: 1
            wispiness: 0.5
            edgeopac: 1
            edgeradius: 1
            period: 1
            fingerlength: 1
            envrefresh: 3
            envradius: 10
            windspeed: 0.1


Can anyone give me a hint with which parameter I should fiddle to make my wavesets look better?

Site note: using linking duplicate is proven to be useful, but it also has some disadvantage. Then I color vertex one of my object, all linked duplicates are being painted the same way...

Re: Shell 126

PostPosted: Wed May 19, 2010 3:01 am
by tachzusamm
What do you refer to when you say "looks terrible"?
The fading line in the center of the water? In this case you could try to reduce the value for opac.end in depthrange much more.
Or are you missing reflections when viewed from close and from a steep angle? Well... IS there something to reflect in this case? You could try to fake an envmap to have "just something" to reflect.

using linking duplicate is proven to be useful, but it also has some disadvantage. Then I color vertex one of my object, all linked duplicates are being painted the same way...

Yes, of course. There is only one real mesh when you use linking; for this reason, you paint on this only one mesh's vertices directly - no chance to get around this. Color values of vertex painting are not stored "somewhere", but directly belonging to the vertices - not to the object.

Re: Shell 126

PostPosted: Wed May 19, 2010 3:33 am
by Egon
tachzusamm wrote:What do you refer to when you say "looks terrible"?
The fading line in the center of the water? In this case you could try to reduce the value for opac.end in depthrange much more.
Or are you missing reflections when viewed from close and from a steep angle? Well... IS there something to reflect in this case? You could try to fake an envmap to have "just something" to reflect.


"IS there something to reflect in this case?" - well, we do have sky...

"You could try to fake an envmap to have "just something" to reflect." - what do you mean?

tachzusamm wrote:
using linking duplicate is proven to be useful, but it also has some disadvantage. Then I color vertex one of my object, all linked duplicates are being painted the same way...

Yes, of course. There is only one real mesh when you use linking; for this reason, you paint on this only one mesh's vertices directly - no chance to get around this. Color values of vertex painting are not stored "somewhere", but directly belonging to the vertices - not to the object.

Yeah. For now it will work for me. Once my objects shapes will be "stable" (I would not need to change them anymore) I will split them into seperate objects and fix vertex painting.