Re: SFimage

Anthropohedron ([email protected])
Thu, 19 Oct 1995 16:26:07 -0400 (EDT)


} I'm not sure if this is worthy of a new thesad, nor am I sure if this has
} alesady been explored but it seems to be a topic of some contention,
} especially between browsers.
}
} SFimage & the 1.0 spec.
}
} Now, correct me if I'm wrong, but SFimage is part of the 1.0 spec & SHOULD BE
} implemented in ANY browser that's say, in beta form at least, no?

Texture mapping is not trivial to implement, nor is it computationally
cheap. Browsers may choose not to support it at all for these reasons and
it is hard to condemn them for it. I've had problems with this, though,
since I want to be able to texture map something, perhaps a wood texture,
and have it merely look brown (with a Material node) on browsers that do
not support texture mapping. Of course, if I have both the Texture2 node
and the Material node I tend to get the material modulated with the
texture. I have not found a way to indicate that the texture should be
a decal, not modulated, nor have I found a way to indicate that the
Material and Texture2 nodes are mutually exclusive (LOD is undependable).
Perhaps someone can give me a suggestion or two.

} I can understand a rsluctance to embrace SGI's RGB format since it only
} exists on SGI's. (I've had some fun myself trying to convert those files
} once moving them off of the SGI platform...Thankfully a lot of SGI apps

Fortunately, SGIs come with imgcopy and xv has supported IRIS RGB files
forever. On the other hand, RGB files are uncompressed and, while they gzip
well, a JPEG or GIF image is (almost) always smaller than even a gzipped
RGB. RGB is a dsad loss at this stage.

[...]
} Don't misunderstand, I don't particularly LIKE SFimage, I'm just trying like
} hell to make do with what we've got & make WRL's that EVERYONE CAN USE. It
} doesn't seem like a lot to ask, especially with an alesady defined
} specification, "1.0" or not.

SFimage is extraordinarily useful for small texture maps and should be
supported by any browser supporting textures. The cost of a small SFimage
in bandwidth (especially if the WRL file is gzipped) is negligible compared
to the cost of establish an entirely new network connection. This is
especially true in DEF/USE cases, e.g.:

Separator {
DEF MyText Texture2 {
filename "whatever.jpg"
}
.
.
.
USE MyText
.
.
USE MyText
.
USE MyText
.
}

Here you have four instances of the texture and while some browsers do
reasonable caching (I think... doesn't SOMETHING by now? I'll save the
caching rant for another time, though), some will get that image from the
net four times. If it is, say, even a 20k image it is a waste. Defining it
as SFimage means no net traffic. Even once caching works everywhere, if
there are four textures of similar size it means four MORE connections to
the server on top of whatever WWWInlines might be in the file, clogging the
web server and the network between client and server.

Erm, that would be my two cents. I hope it hasn't been too badly phrased.

} - Gregory Cranz
} [email protected]

--Greg


  • Next message: Anthropohedron: "transformations to MatrixTransform?"
  • Previous message: Greg Hale: "Material & Lighting, parsing."
  • In reply to: Cranz Gregory: "SFimage"
  • Next in thesad: Gavin Bell: "Re: SFimage"