1  |   Order by index

May 23, 2005, 5:52pm

Here's some more guides I've typed up recently. Might be useful to some...

How to keep frame rates high -
http://www.swcity.net/yabbse/index.php?topic=3496.0
A guide for advanced builders looking to keep lag to a minimum.


How to make linear hills -
http://www.swcity.net/yabbse/index.php?topic=3484.0
For those who can't use terrain features, here's a guide to making long
hills useful for dividing defined areas of land.


How to make pictures blend in perfectly -
http://www.swcity.net/yabbse/index.php?topic=3358.0
A guide for making logos or text images blend into a textured wall
seemlessly.


How to make realistic roads -
http://www.swcity.net/yabbse/index.php?topic=3440.0
My previous thread, thought I'd put it here too to keep it all together :P


- SW Comit

May 23, 2005, 7:39pm

SWCity.net = Down? >_<

May 23, 2005, 8:22pm

No? I heard of the occasional time out, but it should be working fine.
Refresh if it times out.

[View Quote]

May 23, 2005, 9:29pm

Ah, was just a few time outs, working now =D
[View Quote]

May 24, 2005, 6:27am

Please allow me 3 comments:

5. Coronas will cause a ton of lag if you view a corona through another
corona. This is a common problem if you have semi-large "corona
sprites" flying around a concentrated area. Or if you have a bunch of
lights all lined up, with a corona effect.
<<<

The reason is not the corona itself, but that the corona is a "light"
and light sources will cause lag when there are more than 2 of them in
the perception radius (which makes generally all worlds with
illumination and night scenes laggy). A good approach is to put in the
welcome message a note about the maximum recommended visibility (eg.
30m, 60m, 100m) to make people aware of this design when they enter.
Please note that the lag effect of light becomes worse, the bigger the
max light radius is, since you will then notice lights from far away
already (provided they do not limit their radius themseves).

7. High resolution images tend to cause lag when in numbers. I'm not
sure if this is so true though, as AW has a maximum resolution for
pictures (it will download the full size image but the resolution you
see in AW has a max). I vaguely remember reading a long time ago, in
the release notes, that they increased the maximum picture resolution to
512x512.
<<<

Not really - there is no obvious reason why a static texture (in
opposite to auto-animated ((=filmstrip)) and normal animated ((=via the
animate command)) ones) should cause any lag - except for a few cases of
particularly weak graphic cards in combination with weak computers
(reason is there the swap of textures from graphic-Ram to ordinary Ram).
The maximum size is usually determined by the graphic card used - I have
personally successfully used textures of 2048*2048, if a graphic card
does not support them, they will simply not show up and the space stays
"white" or "black" (in case of big masks). A safe size is around
256*256. For computers bought in the past 2 years with an average
graphic card, sizes up to 1024*1024 won't be a problem.

The only "lag" that graphics really cause, is during their download,
because, although AW does not confirm that, the download/frame
calculation modus has changed in the recent client builds and downloads
affect the frame-rate re-calculation a lot more than it used to be,
especially in combination with a low maxCPU value.
After a graphic has downloaded though, its lag potential is almost non
existant anymore and thus, the advantages of big textures (better
detail) will outnumber its temporary disadvantages.

One addition: auto-animated (filmstrip) textures will always put a great
stress on the CPU (make it run hot), because they always refresh with
the actual frame rate - avoid them when you can and try to achieve a
similar effect with the animate command with slow refresh values.

Don't use texturing objects when you don't have to. Tests have proven
that applying the texture directly to the object is faster than having a
texturing object do it instead.
<<<

the direct texture command is also more reliable. :-) When you need the
same texture really thousands of times and got your own object path, it
is more efficient to change the texture name in the .rwx file itself.

May 24, 2005, 1:17pm

[View Quote] I don't see why it should be more reliable, unless you're talking about
texturing objects that don't auto-refresh.

May 24, 2005, 3:27pm

I was about to disagree but I just went into the world and made a lineup of
coronas and looked down the line. Hmmmm I don't get it, this use to cause
insane lag but now nothing...did AWI silently fix it? Ah well, I guess I'll
remove that tip then. Not too concerned about using the light command.
Never really get noticeable lag with em', and the 8 light limit makes them
pretty much useless anyway.


[View Quote]

May 24, 2005, 3:39pm

Ah wait a sec. I only get that corona problem in OpenGL mode, not DirectX.
Did some experiements....
Viewing a coronas through coronas without light = no lag
Viewing a coronas through coronas with light = laggy
Looking over coronas with light = laggy, but not as bad as above
Looking at a ton of simple lights = slightly laggy but not too bad


[View Quote]

May 24, 2005, 3:57pm

Ah yea, the only reason I added this was because we have this area with
hundreds of high res images that form an ultra high resolution map of our
city. And it's laggy as hell for some people. While in comparison they
were able to view most builds just fine.

Here's something from the AW 3.0 release notes:

"Unlike previous versions of Active Worlds, where all textures were limited
to a fixed size of 128 x 128 pixels (or 256 x 256 pixels in the "high res"
CD version), in 3.0 and later a variety of texture sizes are supported,
including 64 x 64, 128 x 128, 256 x 256, and even 512 x 512 (although not
all video cards support textures that large). Active Worlds decides what
size texture to use based on the size of the JPEG original - the larger the
JPEG, the larger the texture. This allows efficient use of texture memory
while simultaneously providing access to a very high level of texture detail
if and when it is required."

I don't recall any change to this system since then, though 1024x1024 would
be a nice addition ;D


[View Quote]

May 24, 2005, 5:52pm

[View Quote] Well, I hardly doubt AWI placed the restrictions in their software per
se, but were just stating that video cards from that era weren't really
supporting anything higher.

Usually developers/multimedia designers read this stuff and design
accordingly, so I'm sure it wasn't really a problem.

I'd think you could take pre3.0 browsers and (if allowed) go into AW and
probably see all the objects normally. That is, if you were using a
current-day video card.

May 24, 2005, 6:00pm

You'd see all the objects normally, yes, but the textures would be 256x256
in 2.2 and 128x128 for anything previous to that. If it's being downsized
on the rendering engine's level, as it specifically says it is, I doubt
there's anything your video card could do about it.

[View Quote]

May 24, 2005, 6:19pm

[View Quote] That's right, I think I remember something beind side that all textures
were resized to a square form.

May 25, 2005, 5:48am

The manual is outdated here, though I remember TechnoZeus updated it
once (for 3.4?) with the correct explanations in it - also regarding the
difference between horizontal and vertical 2^n dimensions. :-)


[View Quote]

May 25, 2005, 5:56am

I did some extensive tests about a year ago or so - I remember that then
I also found a handful of video cards that were not affected at all by
lag from light, while all the ones I used and use are (namely GF400,
GF440, GF4ti, GF5900, GF 6800), in both DD7 and DD8 mode and with all
antialiasing/mipmap switched off. GF4xx has other problems too, namely
the "fog" problem and some graphic cards have a problem when
"background" pictures are used - in all cases, it is not a matter of the
driver, but of the specific card or graphic chip (family).

The impact starts with 2 or 3 ligts and then increases dramatically to
the maximum of 7 - not 8, since 1 is taken already by the directional
ligt source, and this applies not only to DD, but also to OpenGL.
Ssoftware mode is not affected at all, btw - you also can see any number
of lights there.


[View Quote]

1  |   Order by index