search

Mrkebubun / o3d

Automatically exported from code.google.com/p/o3d
0 stars 0 forks source link

Please support more PNG types for texture loads #160

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 

It is currently hard to work with certain types of textures that are natively
supported by GPUs, for example Luminance Only or Luminance+Alpha, or
deeper bit depths or a combination thereof.

PNG natively support a wide variety of formats, but the O3D loader doesn't
know currently how to handle them.

It would be very nice to support texture loading for the following PNG types:

      - 1 Channel PNG (Luminance Only)
      - 2 Channels PNG (Luminance + Alpha)
      - 3 Channels PNG (RGB)
      - 4 Channels PNG (RBG + Alpha) 

It would also be very nice to be able to load 16bit PNGs into floating
point textures, for all the channel cases listed above.

I have attached a simple "PNG bestiary" tar file with a variety of PNG
file types in it if you guys would like to add it.

Original issue reported on code.google.com by emoge...@gmail.com on 29 Sep 2009 at 12:16

Attachments:

GoogleCodeExporter commented 9 years ago 

Attached is a patch that partially fixes the problem by
adding support for 8bit  1 and 2 channel PNGs (LumOnly
and LumAlpha).

Original comment by emoge...@google.com on 9 Oct 2009 at 8:00

Attachments:

GoogleCodeExporter commented 9 years ago 
Hi Emmanuel,
  Thanks for the patch. Looking at the code, I noticed that there's no D3D 
implementation for the new formats.  Additionally, I'm afraid that L8 and LA8 
are not 
supported by all GPUs and it's not safe to assume they will be available in 
D3D. Part 
of the reason we decided to trim down the texture formats was because of the 
lack of 
universal availability.

One thing we can do it use the "feature request" mechanism to request support 
for 
this formats before-hand and allow O3D to run in H/W only if the feature is 
supported.

Original comment by vange...@google.com on 12 Oct 2009 at 8:34

GoogleCodeExporter commented 9 years ago 
Hi Emmanual, 

I thought I'd follow up on vangelis's comments.

Like vangelis mentioned, we'd need this to work on D3D as well before we can 
put it
out. Because apparently L8 and LA8 are not supported by all GPUs we'd probably 
need
to enable it through a feature requirement.  

This link as some info about which cards support what formats.
http://zp.amsnet.pl/cdragan/wizard.php

This link is what feature requirements are.
http://o3d.blogspot.com/2009/07/improving-o3ds-hardware-compatibility.html

If you have time to look into those that would be great. If not we'll have to 
wait
until we have time to do that ourselves before we can integrate your patch.

If you do want to try to tackle it then off the top of my head here are the 
things
that need to be done.

*) Add a "AlphaAndLuminanceTextures" to o3d/core/cross/features.cc which 
defaults to
false
*) Add appropriate tests to feature_test.cc and texture_test.cc
*) Make IsSupportedTextureFormat in o3d/core/cross/renderer.cc fail if
AlphaAndLuminanceTextures feature is not true.
*) edit core/win/d3d9/texture_d3d9.cc and add L8 and LA8 support
*) edit core/win/d3d9/renderer_d3d9.cc and in CheckDeviceCaps check that the 
device
supports those formats if they were requested.
*) edit the sample o3d/samples/generate-textures.html to make samples of these
formats. This will probably require updated 
o3d/plugin/cross/texture_static_glue.cc
*) edit the test o3d/tests/selenium/tests/texture-set-test.html to also test 
these
formats.
*) Double check that GL and D3D match byte order. Are they both LALALA or is 
one of
them ALALAL?  If they don't match a swizzle array will need to be exposed like 
it is
for ABGR32F and used in texture_static_glue.cc

Sorry it's so much work. If you have the time that would be great. If not I'm 
not
sure when we'll be able to get to it but we'll add it to our list of things to 
do.

If you do have the time, rather than a patch file you could just check out the 
code,
edit it live and submit a changelist. That would make it easier to review. It 
would
also make it easier to run the code though the testing system.

Original comment by g...@google.com on 12 Oct 2009 at 9:03

GoogleCodeExporter commented 9 years ago 

You guys are both correct: I completely ignored the d3d part, first because I 
rarely
have to pay attention to things in the windows world these days, but mostly 
because
I am completely ignorant of things d3d, nor do I currently have access to an 
actual
windows box.

I will get myself a vmware windows image with d3d and VC++ over the week-end
and see if I can figure out how to add d3d support, following gmangoog 
suggestions.

As a side note, I am quite surprised by the claims that specific GPUs might not 
support
these two formats. This has been a part of OpenGL since pretty much day one, 
and I've
never come across a specific GPU that didn't support this. I'll research this 
further.

Original comment by emoge...@google.com on 12 Oct 2009 at 9:45

GoogleCodeExporter commented 9 years ago 

So ... I went and tried the d3d caps website, and querying for "texture and 
surface formats available
in Direct3D 8", both L8 and A8L8 seem to be supported by a fairly large number 
of GPUs. I'm not sure
where you guys draw the line for your base feature set, but I'm personally not 
overly concerned with
not having Riva TNT2 cards support this natively.

Also, I went and read 
http://o3d.blogspot.com/2009/07/improving-o3ds-hardware-compatibility.html
and I will note that native GPU support for these type textures should not be 
an issue and should IMO not
be exposed at the O3D API level.

Rationale: If A and LA aren't supported by the hw, I am hoping that D3D and any 
sane implementation of
OpenGL will do the right thing, i.e. expand it to RGB or RGBA before uploading 
it to TRAM, as it makes
things almost completely transparent to the user. Worse case: d3d/opengl can't 
expand themselves and
we do it in the o3d layer. In all scenarios, as long as RGB/RGBA is supported, 
L and LA are as well, at the
expense of a potential increase in TRAM usage.

Original comment by emoge...@google.com on 12 Oct 2009 at 11:24

GoogleCodeExporter commented 9 years ago 
Well, I'm fine with it as long as Vangelis is

Still, checking the caps bits on my machine here I see that L8A8 is not 
supported as
a render target. That means at a minimum renderer.cc CreateTexture2D and
CreateTextureCUBE need to fail if that format requested with 
enable_render_surface
true. (they should also fail for the DXT formats which I think they are not 
currently)

Also, renderer_d3d9 still needs to check for those formats and fail if they 
don't
exist so we'll fall back to software.

Original comment by g...@google.com on 12 Oct 2009 at 11:42

GoogleCodeExporter commented 9 years ago 
>If you do have the time, rather than a patch file you could just check out the 
code,
>edit it live and submit a changelist. That would make it easier to review. It 
would
>also make it easier to run the code though the testing system.

As a matter of fact, I already did: it took me a while to understand the whole 
chromium
workflow, and after I posted the patch here, I went and uploaded a changelist 
with gcl:

http://codereview.chromium.org/261036/show

Original comment by emoge...@google.com on 12 Oct 2009 at 11:52

GoogleCodeExporter commented 9 years ago 
Emmanuel, 
 Are you still interested in completing the d3d side of this?  If not, we can
probably pick it up. 

Thanks
Vangelis

Original comment by vangelis@chromium.org on 29 Oct 2009 at 5:26

GoogleCodeExporter commented 9 years ago 

Hey Vangelis,

Sorry, day job got in the way of me spending time on this until now.

Here's a more complete version of my earlier patch that includes
both D3D and OpenGL support.

It is functional in the sense that I successfully managed to load and display L8
and LA8 PNG textures in the hellocube* samples in a D3D environment.

There is probably some additional work that needs to be done to implement
the render target corner cases mentioned by gmangoog.

Also, I did not have to time to go and understand really well how the platform
depedent swizzle paths work. It's unfortunate because LA8 does require swizzling
on the D3D path and does not on the OpenGL path.

What I have works for D3D, but I suspect it breaks OpenGL because none
of the changes I made viz swizzling are D3D specific.

And unfortunately, I can't test things on the OpenGL path anymore because
the Mac build f O3d is currently broken).

If you guys, being hopefully a lot more familiar with the code base, could
take a look and maybe improve things a bit, I'd appreciate it.

Thx,

    - Emmanuel

Original comment by emoge...@gmail.com on 31 Oct 2009 at 11:19

Attachments:

GoogleCodeExporter commented 9 years ago 

Vangelis,

Just uploaded http://codereview.chromium.org/346046
which implements LA8, L8 for both OpenGL and D3D.

I tested the CL and AFAICT, LA and LA8 textures render
correctly on both Win32+D3D and OSX+OpenGL.

I also included two unit tests.

Thx,

   - Emmanuel

Original comment by emoge...@gmail.com on 4 Nov 2009 at 12:38

GoogleCodeExporter commented 9 years ago 
the build recently changed.

make sure your .gclient file has no "deps_file" line

then 'gclient sync' and build with xcode on mac.  details updated here

http://code.google.com/p/o3d/wiki/HowToBuild?tm=4

I just built and it worked for me on OSX.

Original comment by g...@google.com on 4 Nov 2009 at 12:53