Orientation world really S-L-O-W

[Ric Moore]

I tried turning off gravity and collisions and I'm still getting 1-2
fps. Is there a way to edit out most of the nice trees or something?
Thanx! Ric

--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
Linux user# 44256
https://nuoar.dev.java.net/
Verizon Cell # 434-774-4987

[Morris Ford]

The orientation world is a module in stable. From looking at the art directory, it appears that you may be able to pull out pieces and re-install the module. I haven't tried that yet but it is probably worth a little experimenting. I noticed a green shrub model that is about 1.5 meg. If that is used multiple times and it was removed, things might speed up a bit.

Morris

--
To unsubscribe, reply using "remove me" as the subject.

[Margaret Leber]

On Mon, Apr 5, 2010 at 8:13 AM, Morris Ford <morri...@gmail.com> wrote:
> I noticed a green shrub model that is about 1.5 meg. If that
> is used multiple times and it was removed, things might speed up a bit.

Orientation World has always been very slow to render.

1.5 meg per shrub is rather excessive...I'm guessing there's some
textures in it that are much higher res than they need to be.

[Morris Ford]

I did an experiment of removing that one file and reloading the world and it made a difference. The avatar motion was not as herky jerky and the frame rate was higher. Your process will be to remove dae files until the performance is good enough.

Morris

--

[Morris Ford]

Another experiment. I took out both kinds of shrubs and the house plants and then I tested from a client (not on the server) that has double 1 gig video cards and after an initial sweep around to pick up all the models/textures all movement was smooth and was running 40 - 60 fps. I guess the video card makes a lot of difference. Also, the orientation world was never smooth before no matter what system I tested it on.

[Margaret Leber]

On Mon, Apr 5, 2010 at 8:55 AM, Morris Ford <morri...@gmail.com> wrote:
> I guess the video card makes a lot of difference.

Truer words were never spoken. Having a beefy vidcard is the key to 3D
graphics performance on any modern 3D software.

[Ric Moore]

That would be my guess. It's not usable in it's present form. Ric

[Ric Moore]

True, true. But it would be good to keep an eye out for the laptop users
and their limitations. I'm running an older nVidia card with 256megs of
vram memory in my AMD64 tower. It shouldn't be that bad, ergo the model
can use some re-working for the average user to enjoy. :) Ric

[Nigel Simpson]

Ric,

We've been aware of the performance problems with the orientation world for some time and are working with our graphic artist on a new version. Although the current orientation world is nice to look at, it also is painful to navigate even without the performance problems. There's no point in having an orientation world that most users can't render ;)

Nigel

[Ric Moore]

On Mon, 2010-04-05 at 09:24 -0700, Nigel Simpson wrote:
> Ric,
>
> We've been aware of the performance problems with the orientation world for some time and are working with our graphic artist on a new version. Although the current orientation world is nice to look at, it also is painful to navigate even without the performance problems. There's no point in having an orientation world that most users can't render ;)
>
> Nigel
>

Exactly, thanx!! I'd love to see the old orientation room ported over.
That was a great demo for non-techie clients. Thanx for all you do, Ric

[Jonathan Kaplan]

As an alternative to removing .dae files, you can also edit the loader description file:

http://code.google.com/p/openwonderland-modules/source/browse/trunk/0.5/stable/orientationworld/art/OrientationWorld.mtg

At the bottom of the file are a whole lot of "instance" directives. You can remove instances of (for example) plants by thinning out the various Shrub entries.  A stress test we always meant to do was to break this file up so that each object was a separate cell. You could do that with a script, generating separate .mtg files for each object, and then a separate -wlc.xml file in the wfs.  That way you could thin out the world using the normal in-world tools.

[wezzax]

I think I have a beefy vcard! nVidia GTX-275!
But it still takes more than awhile to render Orientation!

I think where there's enough resources. It should have saved the
rendered objects in ram, or worst, write it to hdd. So no rendering
is needed for the same thing or the basic thing, like the Orientation
world!!

On Apr 5, 9:44 pm, Margaret Leber <margaret.le...@gmail.com> wrote:

[Nicole Yankelovich]

This might be a long-shot, but is there a way to check to see if your computer is actually using your good graphics card? I know that one person I was helping on a Windows 7 PC had a good graphics card, but the default was set to use the built-in integrated card. Orientation world performs extremely well for me on both a Mac and a two-year-old Windows Vista PC with an older nVidia card.

The other thing to check is if your graphics driver software is up-to-date. Updating to the newest software has helped a number of people with performance problems.

Nicole.

[davenz]

Great to hear this is being looked into :) Quadro FX 540 on an
OpenSolaris host with the latest nVidia drivers, and the Orientation
world is unusable. I'm currently attempting to build OpenArena to
compare 3D OpenGL performance.

I personally think low-end graphics hardware or integrated chipsets
are a good baseline to aim for decent performance on. Integrated
graphics chipsets particularly from AMD are sufficiently advanced to
run some quite impressive FPS titles, apparently graphically far more
complex than WL, for example the following which was captured on some
very low-end hardware:

http://www.youtube.com/watch?v=ounusFFWAjc

You'd also find low-end hardware in thin clients - and I happen to
think WL would make an excellent marriage with thin clients for a zero-
configuration collaborative learning solution.

Cheers
Dave

[David Leoni]

Talking about performance, when assessing JMonkeyEngine capabilities I
had a look at Nord game http://www.nordgame.com/ which uses it as its
graphic engine and I found the graphics was quite good albeit being a
bit cartoonish in style. Some scenes contained lots of objects
rendered with some sort of shaders and the framerate seemed to be
constantly > 40 fps (this is my personal judgment, actually there was
no fps indicator). On the other hand WL seems to be quite slow even
with simple scenarios, it's not uncommon for me to get 15/20 fps (and
I have a geForce8800GT with 1 GB of dedicated ram). I read somewhere
someone complaining that the jMonkeyEngine leaves the programmer too
much freedom about how to render the scene. These two facts made me
suspect that maybe the WL client rendering system needs some
reworking, it doesn't seem to be only a matter of texture sizes.
Anyway, I presume there will be major changes in any case if and when
WL will upgrade to jMonkeyEngine 3.

Cheers,
David

[Jonathan Kaplan]

Wonderland definitely leaves a lot on the table in terms of performance, especially on low-end hardware. There are plenty of areas to investigate here:

- Collada models not optimized for real-time rendering

- JME / MTGame buffer management

- MT Game threading overhead

- Avatar processing or shaders

- Picking and collision detection

- Garbage collection and GC pauses

So I guess the question is: how can people help? Obviously, finding problematic use cases -- particular models, configurations of the world, etc that cause performance hits -- is helpful. But we also need people familiar with tools like the yourkit, the Netbeans profiler, or even DTrace and OpenGL debuggers to start benchmarking the client and identifying the bottlenecks. Once we can find what the performance hits are, we can start discussing how to solve them.