Night Time Zephyr Cove

[Nadnerb]

Well, I won't comment about the rest, but the NURBS comment is plain wrong. Plasma does not support such surfaces, and hence, none of their ages use them. The geometry the plugin generates is very close to (if not exactly) what Cyan's tools generate.

Cyan makes rendering their ages more efficient using visibility regions that hide geometry when it would not make sense to render it. Andy's complaint is that they don't seem to work with exports from the plugin. Something which I have yet to confirm or refute, but will eventually have to be looked into.

[andylegate]

Not sure what is going on, tried working with Paradox, and he was stumped also. What happens is, the geometry stops being drawn, period, and will not render at all, or it still get's drawn no mater what. It's like it doesn't care that there is a region at all, more like it's just paying attention to the ALC whether to draw or not, but not based upon where the avie is (in or out of the region).

I'd look into it more myself (as zephyr needs it desperately now) but I don't know squat when it comes to the pyprp.

As far as upgrade or not.......

Sigh. It's a debate, that's for sure. However, i personally feel (and it's just my opinion, nothing more) that we are now at a tech level that can allow us to make Ages that look even better than the original Uru Ages (yes, I can hear the gasps of "blasphamy!" out there). But doing so will cause people to need to upgrade.

One reason that I don't flinch at the idea of upgrading, besides the fact that being a electronics engineer, I'm quite at ease inside my computer, is the pure and simple fact that I had to upgrade my computer in some shape or form every time Cyan came out with a new Myst game!

But of course then you worry about those faithful to playing Uru, who really want to enjoy fan Ages, not being able to because we start making the Ages so hirez, that their systems can't handle it.
The old grizzly part of me wants to go: "Tough! A serious gamer knows you have to keep upgrading your computer to keep up with things. Get with the program!"
But then another part of me also realizes that may not be realistic for many people.

If I can find a way to make a hi/low rez version of Zephyr, I'll do it. I've even thought seriously about doing a different version of Zephyr that's much more low rez and posting it on the ULM for those that need it.

I mean, I've already caught hell from people: my geometry for the cliffs and rocks. I had them high so that I could make the rocks look more fluid and flowing looking. I got a lot of "Outstanding!" for that from so, but then a lot of complaints about performance. So I lower the polys to make the performance better, and I get people pointing out that the geo's now look too sharp, unrealistic.
That right there is almost enough to drive you insane.

In any case, this will always be a hot debate with people. Those that feel we shouldn't push the boundries, and those that think we should.

[Grogyan]

Yeah, I knew I could be wrong on the NURBS thing.

There is a number of other visual bugs that might be fixed with vis region, but the problem would still exist when viewing the whole beach and cliff, its still my feeling that it needs to be high poly again.

In MOUL if you remember when you got to the office and stood over the vortex, there really wasn't that much of a problem to render it, would breaking up ZC beach and cliff into several meshes help?

[andylegate]

The cliffs and beaches are broken up in to several meshes, and have been for a while. The flickering of textures that you are experiencing did not start happening until I put in the wave set for the ocean. I experience some of it myself with my system, but only in a couple of places.

The problem is this is new territory for us, and not well mapped out. Thank god I had imported Cyan's Ages before support for importing was dropped, I was able to study the meshes that Cyan did for Teledahn and Ahnonay Sphere 1. I've patterned my waveset meshes after theirs.

However, Cyan has something we don't: a high and a low res surface for these meshes. you can see them plain as day when you import the Age.

Having workig Visregions will help, as I did a little bit of experimenting with Zephyr. I exported it after deleting the Waveset, and the flickering went away. I tried exporting it with the waveset, but I had removed the tunnels and cavern, and performance went WAY up.
So I know that as soon as I can use visregions, many of the "bugs" you're experiencing will go away.

[D'Lanor]

Obviously we should be looking to the system requirements for Myst 5 or MOUL for our Ages on CC.

Agreed, and now that I re-read the specs on the box they do appear to be kind of low. But I can tell you that the pc which has trouble with some of the user ages was quite capable of running MOUL, although shadows had to be off in some areas.
Actually I have a new high end laptop that can run any user age without a problem, but I am still using the old pc for testing purposes to make sure that everything works on low end systems as well. We have to keep in mind that the average Uru player is not exactly the uber gamer type with the latest greatest hardware.

[D'Lanor]

Rather than visregions I propose another optimization: ditch the unnecessary camera avoiders. I wonder if people realize that since PyPRP 1.0 all objects are camera avoiders by default? Unless you give them the following Alcscript...

Code: Select all

Object:
    physical:
        campassthrough: true

The only objects that need camera avoiding are walls and objects at avatar height which you can walk past. I have been doing this consequently for Prad, although in a small age like mine it probably makes little difference.

I do not know how exactly the camera avoiding routine in Uru works but I should hope that the actual computation is only done for objects close to the avatar. However, even then the game has to constantly check the relative position of the avatar against all those camera avoiders. I would not be surprised if this turns out to be the main cause of the laggy user age problem.

I realize that setting the Alcscript for every object can be a lot of work in a large age, but if you are really interested in optimizing your age for low end systems you should probably give this a try.

I would rather see the object default reverted back to non camera avoiding though.

[Aloys]

Just to make sure: by "all objects are camera avoiders by default" you mean all objects with collisions, right?

[D'Lanor]

This post is where I read this information for the first (and only) time. It does not make clear if this is true only for colliders. So I was assuming that this really meant all "normal" objects.

[andylegate]

BARF!!!

Wow...that would be.....a LOT of script to add......hehehehehe. Take me most of one day to do that for Zephyr...and I'd LOVE to try it as it's a big Age and might help make a BIG difference......hmmmmm

Well, RL is imposing on me right now anyway and I don't have the time...still that's a good point you brought up D'Lanor, it could help a lot.....gotta keep it for the tunnels and cavern though, don't want people's cameras moving through to the outside of them.

[Chacal]

Making visible objects camera avoiders causes the same problem as making them colliders: most of the time they have too much detail, which bogs down collision detection.

I know I'm repeating myself, but it would be best to have dedicated colliders and camera avoiders which, being invisible, can have much simpler geometry, which makes collision detection much easier to compute. I still think that almost no visible object should be a collider.

Maybe the default for the plug-in should be that only colliders are camera avoiders. Perhaps it is already that way.