Wavesets, can we play?

[D'Lanor]

Even with shadows enabled for my 3 kickables alone things are coming to a grinding halt. The kickables do have a high vertex count though. So I will have to leave those off as well. No problem, my shadows are rather faint by design anyway since it is either clouded or night.

To get back on subject, I am busy tweaking my waveset variables now. It is not as frightening as it seems at first glance.

[boblishman]

Thanks for the python script Nadnerb ... saved me a lot of time ... works perfectly!

now, a quick question ... (yes, I know this is all new but I can't find any reference to this is the tutorial) ... I have some weird thing going on with my avatar reflection - the "world" is fine) ... here it is :

waveset.jpg (74.83 KiB) Viewed 3170 times

d0 you know what is causing this ... and how to "fix" it?

[D'Lanor]

It does that with kickables too. The reflection algorithm does not seem to like objects in the water. So the envradius should probably be set to at least the distance of the shoreline that is farthest from the waveset center.

Edit: I tried that but even then the avatar reflection appears on the opposite side of the water. Another workaround is setting the envrefresh to a high value so that Uru doesn't draw the avatar at all unless it stands there very long.


I have different problems. If I use any waveset mesh that is not a plane or a very simple grid nothing shows up or shows up briefly at link in and then disappears (similar my Er'cana syndrome). So much for matching the terrain geometry... So I probably won't be seeing the nice waveset creations others will make.

Right now I have to use a plane that intersects the terrain. So no soft edges for me. Could that be covered up with shores or do they have to be at the actual edge of the mesh?

[Marcello]

Wiki suggestion: Waveset library

I think it could be very useful to create a set of wiki pages showing images of wavesets and the corresponding settings. That we people can start fast and work from the supplied experiments.

[Aloys]

Thanks a lot for the script Nadnerb, it probably saved many people a lot of time..

you will need to remember to turn off shadbuf in all your materials to prevent them from casting dynamic shadows

This probably won't be a popular opinion among you PyPRP devs, but I think this should be the other way around.
I know it makes more sense to have the button clicked to enable stuff, but it would make more practical sense to have it disabled when when the button is clicked because we won't use shadows for 99.99% of our objects; and it will quickly become very annoying to click this button each time we create a new material. (not to mention that we will forget very often..)
(this is very much like the 'ambient' setting BTW; although it's another discusion)
In a word: invert the current behaviour.

[Paradox]

I can understand exactly where you're coming from, and we (the developers) did have a heated discussion about it when we were testing it.
The goal of PyPRP however is to use as many Blender properties as possible, for their intended use. In Blender, that button causes an object to cast shadows, and so it will do the same in PyPRP. This helps to ensure that what the Blender Preview window sees is similar to what Plasma sees.

[greendragoon]

The tricky part of it is that Uru has a couple methods for shadows, two of which make use of the shadbuf button. It gets tricky when one has to remember to turn on shadbuf if you want to bake some shadows, but turn in back off when you go to export. My personal opinion, and this is simply a suggestion, would be to implement the real-time shadows as a AlcScript property. Since the real-time shadows only get used on a couple of objects in a scene, this seems like it would be easier to adjust to.

[Nadnerb]

In said heated discussion, I started out on the side saying that we shouldn't use the button at all and instead use a script prop because the button defaults to on, but now I agree that it makes logical sense for the button to act the same way as someone who knows blender would expect it to. It's really a line between making it easy for people who want to do minimal clicking, and intuitive for those who know how things are supposed to work. Intuitive wins out in this case simply because it is so easy to mass disable this button using a script. If that ability did not exist, then I would go for not using the button at all and making it a script property.

Edit: greendragon makes an interesting point. If the current behavior was inverted, than shadows would not be cast during the baking process in blender by objects that will cast real time shadows in Uru. Some discussion on exactly how logical and useful this is will be necessary.

Also, about the avatar reflections. You should know that the waveset will never reflect your avatar in a "correct" fashion unless you stand exactly envRadius away from the envCenter. It would therefore be preferable to turn off the avatar reflections. This can be done by setting the "incCharacters" variable. Currently only two values have been tested. 0 shows both the avatar and the environment, 1 shows only the avatar. More info will be available when we get around to testing it, or you get around to experimenting with it.

[boblishman]

This can be done by setting the "incCharacters" variable. ...

how do I do that ? (it's not mentioned in the wiki tutorial) ...

[Nadnerb]

errr... that would be because it's a property of the dynamic envmap, rather than the waveset.... Here are the current scriptable parameters for the dynamic envmap. (subject to change, these ought to be settable through blender's interface, but since wavesets don't have a material layer for the envmap, not sure what's going to happen)

Code: Select all

<object>:
    dynenv:
        hither: 0.3
        yon: 10000
        inccharacters: 0
        refreshrate: 0.5
        width: 256
        height: 256

In the case of a waveset, <object> is the same as the waveset.