[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebGL NPOT texture support




That doesn't work well with MIPmapping though - when the map repeats, the
'fract()' call makes two adjacent pixels have texture coordinates that
differ by the width of the sub-map - and that causes the MIPmapper to
assume that you need to drop all the way down the MIP hierarchy to some
really fuzzy average.  Net result is that you get lines between the map
repeats.

There is a way around that but it entails computing your own texture LOD
(based on the un-fract()'ed texture coordinates and the ddx()/ddy()
functions) then use the tex2DLOD lookup...but sadly those things aren't
supported in WebGL either.

However, if your map doesn't need to repeat, that's something you can live
with.

  -- Steve

Chris Dalton wrote:
>
> You could still tile them with fract():
>     - find your normalized texture coordinates
>     - fract()
>     - transform to the image's position within the atlas
>
>
> On 11/17/2011 09:42 AM, Erik Möller wrote:
>> Makes tiling hard though.
>>
>> On Thu, 17 Nov 2011 17:32:06 +0100, Won Chun<wonchun@google.com>  wrote:
>>
>>> Another option is to atlas all your 2-D images together (called CSS
>>> spriting in the web-world). You'd have MIPmapping so long as you took
>>> care
>>> of padding your boundaries, and it would be higher performance because
>>> you'd have fewer texture state changes during rendering.
>>>
>>> -Won
>>>
>>> On Thu, Nov 17, 2011 at 10:24 AM, Tony Parisi<tparisi@gmail.com>
>>> wrote:
>>>
>>>> Benoit -
>>>>
>>>> Wouldn't another option be to have the browser implementation resample
>>>> any
>>>> NPOT images? i.e. not do a WebGL extension?
>>>>
>>>> Tony
>>>>
>>>>
>>>> On Thu, Nov 17, 2011 at 7:20 AM, Ashley Gullen<ashley@scirra.com>
>>>> wrote:
>>>>
>>>>> On 17/11/2011 15:11, Benoit Jacob wrote:
>>>>>
>>>>>> On 17/11/11 09:49 AM, Ashley Gullen wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm writing a 2D game engine in WebGL (see www.scirra.com), and
>>>>>>> this
>>>>>>> is
>>>>>>> my first mail to the list - apologies if this has been discussed
>>>>>>> before.
>>>>>>>
>>>>>>> I've found the power-of-two restrictions in WebGL a little
>>>>>>> inconvenient,
>>>>>>> since NPOT textures are common in 2D games. It seems a shame that
>>>>>>> in
>>>>>>> WebGL NPOT textures can't be mipmapped or directly tiled without
>>>>>>> stretching to a POT texture first. I've done some work with desktop
>>>>>>> OpenGL and found the GL_ARB_texture_non_power_of_**two extension to
>>>>>>> be
>>>>>>> widely supported and very useful for this situation: it allows
>>>>>>> direct
>>>>>>> tiling and mipmapping of NPOT textures which is great for 2D games.
>>>>>>> There does not appear to be an NPOT extension for WebGL. Could I
>>>>>>> suggest
>>>>>>> that one be added to indicate the relaxing of POT rules? Since many
>>>>>>> desktop systems seem to support it this means the workarounds could
>>>>>>> be
>>>>>>> disabled on these machines for a better gaming experience.
>>>>>>>
>>>>>> An important data point to discuss that is: how widely is
>>>>>> GL_OES_texture_npot supported on current mobile devices?
>>>>>>
>>>>>> I think I might lean toward adding a WebGL extension for NPOT
>>>>>> textures
>>>>>> as we already have some extensions that are not well supported on
>>>>>> mobile
>>>>>> devices anyway; but this is a little bit more dangerous as textures
>>>>>> are a
>>>>>> basic feature and this opens the door to whole games that wouldn't
>>>>>> run at
>>>>>> all on mobile devices.
>>>>>>
>>>>>> Benoit
>>>>>>
>>>>> I thought support might be rare among mobiles, my aim was simply to
>>>>> have
>>>>> it as a convenience for desktop systems which do commonly support it.
>>>>> I
>>>>> don't think it's much of a risk since some old desktop OpenGL 1.x
>>>>> systems
>>>>> don't support it either, so it's always been the case even on the
>>>>> desktop
>>>>> that you assume textures must be power of two, unless the presence of
>>>>> that
>>>>> extension indicates otherwise.  Since I anticipate WebGL will usually
>>>>> be
>>>>> used while wrapped inside some framework (like the engine I'm
>>>>> developing),
>>>>> this would be a useful feature for library writers who can implement
>>>>> it
>>>>> correctly.  Also anyone writing a WebGL app with experience on the
>>>>> desktop
>>>>> will also be aware of how to use the extension correctly.  So I don't
>>>>> really see this breaking things.
>>>>>
>>>>> Ashley Gullen
>>>>> Scirra.com
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------**-----------------------------
>>>>> You are currently subscribed to public_webgl@khronos.org.
>>>>> To unsubscribe, send an email to majordomo@khronos.org with
>>>>> the following command in the body of your email:
>>>>> unsubscribe public_webgl
>>>>> ------------------------------**-----------------------------
>>>>>
>>>>>
>>>>
>>>> --
>>>> Tony Parisi                             tparisi@gmail.com
>>>> CTO at Large                         415.902.8002
>>>> Skype                                     auradeluxe
>>>> Follow me on Twitter!             http://twitter.com/auradeluxe
>>>> Read my blog at                     http://www.tonyparisi.com/
>>>>
>>>>
>>>>
>>
>
> -----------------------------------------------------------
> You are currently subscribed to public_webgl@khronos.org.
> To unsubscribe, send an email to majordomo@khronos.org with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------
>
>


 -- Steve


-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------