1  |   Order by index

Mar 2, 2003, 7:46pm

There should be a more obvious differentiation besides the current length x (length *
#) ones. Some sort of different extension maybe.

--Bowen--

Mar 3, 2003, 5:24pm

There would be a huge disadvantage to that, actually... AW currently lets you use either one without specifying an extension in most cases, but it would no longer be able to do that because it would need to know what extension to look for when attempting to download the files. This would break a lot of old builds, and cause a lot of failed download attempts.

TechnoZeus

[View Quote]

Mar 3, 2003, 7:51pm

[View Quote] OK, top left pixel = red... animate... top left pixel != red... not animate. I'm
sure it won't make any animations look bad to have the top left pixel being red.

--Bowen--

Mar 3, 2003, 10:46pm

On the contrary... Since some animations use very small frames, a single pixel can litterally make a "big" difference.

There is something that could be done though, to make it possible to force any texture to be or not to be treated as a filmstrip.

I've been tossing this around in my head for years, and have sent in some simple suggestions based on it a long time ago, but nothing recently or in as much detail as I have worked it out.

All that needs to be done, is to add optional "hframes=" and "vframes=" parameters to the animate, texture, and picture commands, which would force the texture to be treated as a filmstrip with the secified number of frames in the horizontal or vertical directions. Frames would display in order from left to right, and top to bottom. A negative number could be used to reverse the order in that direction. For example, hframes=1 vframes=-3 would divide the texture into 9 textures vertically, and display them in order from bottom to top.

An "hframes=" or "vframes=" value of 0 could represent "automatic" so that for example, hframes=0 vframes=1 would treat it as a horizontal filmstrip "if" the horizontal size was an exact multiple of the vertical size, where-as hframes=1 vframes=0 would treate it as a vertical filmstrip if the vertival size was an exact multiple of the horizontal size, and hframes=0 vframes=0 would check first to see if it should be treated automatically as a vertical filmstrip and if not then it would check to see if the texture qualified as a horizontal filmstrip.

An additional "framerate=" parameter could specify the maximum frames per second, such as framerate=0.1 for a single frame change every 10 seconds. This actually should be added whether the hframes and vframes parameters are added or not, and there should also be a world setting for maximum filmstrip framerate, which would over-ride this command.

TechnoZeus

[View Quote]

Mar 4, 2003, 3:25pm

If you think about that, you'll see that it's just nonsense.

The textures are JPEG format, that's why you

- should keep JPG/JPEG as the file extension
- don't have much influence on the exact color of any pixel

And how does the browser know how many frames one animation contains?

Btw.: there _is_ an different way to have animations already, without
leaving the standards. The animate command does not require a special
picture size.


[View Quote]

Mar 4, 2003, 3:58pm

[View Quote] It would still use the same system, it just checks to see if the red pixels is there
first. One red pixel out of however many frames won't be that noticable, even if it
is a large animation.

> Btw.: there _is_ an different way to have animations already, without
> leaving the standards. The animate command does not require a special
> picture size.

Yeah, but I don't want my textures to animate just because they hapenstancely fall
into the range of width * (width * #). Sure, I could turn it sideways, but then I
have to re-UV things... and such.

--Bowen--

Mar 4, 2003, 5:53pm

You didn't read what I wrote : you cannot color just one pixel in
an exact color in JPG, it will influence the neighbours and will
be influenced by the neighbours.

What about just making your not animated picture just one pixel row
shorter or longer?


[View Quote]

Mar 4, 2003, 6:29pm

[View Quote] Then you have an empty row...

A completely 255 red pixel will not make neighboring pixels 255 red. It's just not
that noticable... how about a prefix to denote it's an animation. They're just
ideas. Hell, why not just get an image format that's made for animations; GIF for
example.

--Bowen--

Mar 4, 2003, 8:25pm

"bowen" <thisguyrules at 7k2.4mg.com.ANTISPAM> wrote in
news:3e650cc3 at server1.Activeworlds.com:

> Then you have an empty row...
>
> A completely 255 red pixel will not make neighboring pixels 255 red.
> It's just not that noticable... how about a prefix to denote it's an
> animation. They're just ideas. Hell, why not just get an image
> format that's made for animations; GIF for example.

After you compress the JPEG, that pixel won't stay #FF0000. GIF is patented
and absolete. It might be an idea to support MNG (Multi-image Network
Graphics, the animated version of PNG), and of course PNG.

MNG homepage:
http://www.libmng.com/pub/mng/index.html

KAH

Mar 4, 2003, 8:27pm

"kah" <kah at kahnews.cjb.net> wrote in
news:Xns9334EE382418Akahatkahnewsdotcjbdo at 64.94.241.201:

> patented and absolete.

Wow, I'm tired now. That's "obsolete".

KAH

Mar 5, 2003, 7:35am

You're right that you can't color code a single pixel in JPEG format, because it uses lossy compression and like you said... doesn't leave you with much control over the exact color of any specific pixel.

To answer your question about how the ActiveWorlds browser knows how many frames are in one animation, it divides the height of the image by it's width. If the result is an exact integer, that's the number of frames. If not, the texture isn't treated as a texture. As I was saying though, it would be "possible" to add extensions to existing commands that would allow the number of frames and the maximum frame rate to be specified directly.

Since any texture is stretched to fit the surfaces it's applied to, there is really no disadvantage to the filmstrip method in 3D under most circumstances except for the lack of control over frame rate, which could be corrected with the addition of a simple command extension, and/or a maximum filmstrip framerate setting.

TechnoZeus

[View Quote]

Mar 5, 2003, 1:46pm

I know how AW currently does it - but how should it do it with Bowens
idea in effect - detected through the (impossible) red pixel and not
through the size?



[View Quote]

Mar 5, 2003, 2:03pm

GIF itself is still free I think, it is just one of the
compression methods that is claimed to be patented, the
LZW (or was it LZH?) compression - the patent should be
long outdated as the method is not "state of the art"
anymore but some weirdos decided to make new patent laws.

Even simple ZIP compressed BMP should do for a lossless
compressed format as it is stored in the cache uncompressed
anyway, AVI in its simple form would be another option
but no common format beats JPG so far for scaleable(!)
lossy compression with full color depth. Supercomressed
GIF is sometimes smaller for animated textures but supports
only about 250 colors then, as supercompress doesn't work
together with local palettes.

Maybe a second supported format would be a nice option
but JPG still has advantages that most other formats don't
have.


[View Quote]

Mar 5, 2003, 2:11pm

[View Quote] I think it's LZH, sounds familiar.

> Even simple ZIP compressed BMP should do for a lossless
> compressed format as it is stored in the cache uncompressed
> anyway, AVI in its simple form would be another option
> but no common format beats JPG so far for scaleable(!)
> lossy compression with full color depth. Supercomressed
> GIF is sometimes smaller for animated textures but supports
> only about 250 colors then, as supercompress doesn't work
> together with local palettes.
>
> Maybe a second supported format would be a nice option
> but JPG still has advantages that most other formats don't
> have.

What about the MNG or whatever it was that KAH suggested? :) PNG and MNG would be
great.

--Bowen--

Mar 5, 2003, 3:48pm

"bowen" <thisguyrules at 7k2.4mg.com.ANTISPAM> wrote in
news:3e6621a9$1 at server1.Activeworlds.com:

> I think it's LZH, sounds familiar.

Actually, it is LZW. BTW, there are two patents on the same thing (the
USPTO is such a great example of competetent civil servants, isn't it?),
one owned by Unisys and one owned by IBM. The Unysys patent expires in the
US on June 20th this year, the IBM patent expires sometime this year, I'm
not sure when. Even if those patents expire, GIF is still inferior to JPEG
and PNG/MNG. I think AW really needs support for PNG, as it's compression
is lossless, and often the end result can turn out smaller than lossy-
compressed JPEGs.

KAH

Mar 5, 2003, 3:49pm

[View Quote] Yup, not to mention it's free : www.libpng.com

--Bowen--

Mar 5, 2003, 3:49pm

"technozeus" <TechnoZeus at usa.net> wrote in
news:3e65c4c5 at server1.Activeworlds.com:

> To answer your question about how the ActiveWorlds browser knows how
> many frames are in one animation, it divides the height of the image
> by it's width. If the result is an exact integer, that's the number
> of frames. If not, the texture isn't treated as a texture. As I was
> saying though, it would be "possible" to add extensions to existing
> commands that would allow the number of frames and the maximum frame
> rate to be specified directly.

It's considered a texture anyway, just not an animated one.

KAH

Mar 5, 2003, 5:13pm

Actually, zipped bmp files used to be supported by Active Worlds. In fact, I'm pretty sure it was looking for them "first" and looking for the jpg files only if the zip file wasn't found. The problem with this, is it caused a lot of failed downloads because there was no way for the Active Worlds browser to actually know which file format to look for.

TechnoZeus

[View Quote]

Mar 5, 2003, 5:19pm

GIF may not compress as well as PNG, but it's really not such a bad format if you actually take advantage of it's capabilities. I think it would be nice to have support for a format that allows compression, animation, individual frame delays, optional looping, and transparency, all built in without loss of image quality.

TechnoZeus

[View Quote]

Mar 5, 2003, 5:24pm

I don't know the answer to that. Personally, I wouldn't recommend doing it, but I guess is I was going to try to implement such a thing I would probably consider comparing that one pixel with the rest of the entire image to see if it is at least as close to pure red as any other pixel, and at least a little closer to pure red than some of them. Then, go back to dividing the images height by it's width, since there isn't much other way to encode the number of frames into a jpg file. That's, I think, about the best you could do with such a method.

TechnoZeus

[View Quote]

Mar 5, 2003, 5:27pm

Yep... that was a typing error. Thanks. I had meant to say, that if it's heaght divided by it's width is not an integer, then "the texture isn't treated as a filmstrip animation."

TechnoZeus

[View Quote]

Mar 6, 2003, 2:46pm

"technozeus" <TechnoZeus at usa.net> wrote in
news:3e664dae at server1.Activeworlds.com:

> GIF may not compress as well as PNG, but it's really not such a bad
> format if you actually take advantage of it's capabilities. I think
> it would be nice to have support for a format that allows compression,
> animation, individual frame delays, optional looping, and
> transparency, all built in without loss of image quality.

That's what MNG does :-)) It's got a bunch of other advanced (and may I say
rather unnecessary) features too. Check the link I posted a few replies
back.

KAH

Mar 6, 2003, 5:51pm

Not bad... aparently made by the PNG group, and claims to have support for both lossy and lossless compression, animation, transparency, data streaming, etc. There is of course, the down side in their recommendation that the JNG subformat have a different file extension, in that it again means specifying a file extension is necessary, but if AW were to continue to treat files without an extension as signifying JPG and add in support for other extensions if specified explicitly, this could be a nice format to have support for. Looks like it's being very slowly accepted by the Internet community in general, based on what I've seen on their web page. Perhaps that's because of the fact that other file formats got their foot in the door first. :)

TechnoZeus

[View Quote]

1  |   Order by index