[x3d-public] X3D features missing, but desired, by a game engine

[doug sanden]

> > I had a theory/hypothesis about how the specs table 17.2, 17.3 could end up a bit awkward:
> > back in the old days when internet was just starting, and low bandwidth (remember
> > dial up modems? and when 19.2kbaud was hot - big improvement over 9600?)
> > image files would be the last thing to show up, if ever.
> > So material color was what it would thunk to while waiting. In other words,
> > the color would be a placeholder for image texture, in case the image file
> > never showed up. So 'replace' made sense -the image and color were doing the same job.
> > Fancy blending modes were the last thing they were thinking of.
> 
> This makes sense, indeed.
> 
> My other theory was that someone thought that (back in the old days)
> multiplication "texture * material" has non-zero cost.
> 
> In any case, neither of these are valid arguments anymore, I think.
> *Everyone* right now is by default multiplying the "texture * material
> color" (Blender default material, Unity3d default material, Collada
> default material, Spine... every format I can think of), otherwise it
> seems like a wasted opportunity. And this multiplication has a
> zero-cost on GPU, as far as my practice shows:)
> 
> So, I would like to update the X3D to also do this by default. It also
> makes the spec more consistent (making multi-tetxuring more in line
> with single-texturing; the multi-tetxuring nodes always by default
> multiply, for both grayscale and RGB).
> 

Michalis,
Sounds good.  f(web3d file version)?

> > Detecting grayscale image after image library has loaded the image in a generic way:
> > recent freewrl runs a cpu intensive test for R==G==B when loading image files, in separate loading thread
> > - starts with first pixel, runs till it finds a difference or end of image
> > - if no difference, sets number of color channels to 1 (else 3) (plus alpha). Then in above code
> >                         channels = getImageChannelCountFromTTI(node->appearance);
> > returns channel count for influencing use in shader
> 
> I am doing it in Castle Game Engine too, to more efficiently deliver
> images to GPU (grayscale image, without alpha, is 4x smaller than RGBA
> image after all :).
> 
> But I don't think that such detection should be used to decide whether
> the texture is "Intensity" or "RGB" texture (with respect to the
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/lighting.html#t-Litcolourandalpha
> ). This makes it impossible for texture author to mark the texture as
> RGB in GIMP/Photoshop (thus forcing the "multiply" behavior in X3D, by
> storing the image using RGB).
> 

Image header > Ouch - assuming freewrl can ever conform to web3d v4.0, it would need work:
3 of freewrl's supported platforms use image loader libs that load generically - gdiplus image loader (win32), WIC image loader (uwp) and Imlib (linux). All I get is RGBA, rows x cols. So I don't see the header details. 
For a few other platforms freewrl is using separate jpeg, png, gif libs.

Q. what are the relative pros and cons of putting an additional field on ImageTexture node to say how it should be used / how many channels should be used ./ how many channels to interpret it as having? For example all the other renderedImaged etc how would they work either way?
Would that help with renderedTexture somehow?

Or any other options besides image headers? Does someone have a sniffer function for getting the details without needing an image lib? How hard would that be?

-Doug


> See also "18.2.2 Texture map image formats" ,
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/texturing.html#TextureMapImageFormats
> . It describes how to decide whether texture is grayscale / RGB, and
> it seems to suggest to me that one should look at the image header
> (how the image is encoded), and *not* analyze image contents for this
> purpose.
> 
> So, analyzing the image contents may be done by CGE or FreeWRL for
> optimization purposes (takes longer to load, but may render faster),
> but it should not cause a difference in the observed behavior by user.
> 
> I think that this would be best, and also friendly (not surprising) to
> X3D / texture authors.
> 
> Best regards,
> Michalis
>