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

RE: [Public WebGL] Best practices questions



Thank you for the quick response.

That’s what I have expected and matches mostly with the requirements for a general 3D engine. So I can continue with prototyping the engine for the test.

You refer to the vertex texture limit in our FAQ. As there are some other limitation parameters defined in the interface I have another question. 

Does anybody know if there are any plans to provide a table with theses values for different browser/platform/GPU combinations? Query all the limits would best praxis for sure. But game developers like such tables to have an idea what they could expect in the wild before starting to implement the engine and let the artists produce content. 

Maybe I think to big here as I have done large 3D project work in the past.

Von: Gregg Tavares (wrk) [gman@google.com]
Gesendet: Freitag, 7. Januar 2011 00:39
An: Kornmann, Ralf
Cc: public_webgl@khronos.org
Betreff: Re: [Public WebGL] Best practices questions





On Thu, Jan 6, 2011 at 2:53 PM, Kornmann, Ralf <rkornmann@ea.com> wrote:


Hello everyone,

I am new to this list so please excuse me if this has already discussed in the past. We are developing strategy browser games for core gamers. As this is a fast moving market we are always locking for options to improve the player experiences. 3D seems to be the next big thing. Therefore we are currently evaluating the different options.

I know that the current implementations are not final and the performances behavior may change. But I hope that the implementers have already developed a common sense how to use the API from the JavaScript side.

1.       Render state change tracking: Most 3D APIs pass all state changes to the driver/hardware. Therefore it’s recommended to check for changes on the caller side. If this is true for WebGL, too? Or would the checks redundant?



Yes, it's best not to do redundant state setting. Better to design your engine so it doesn't do this by design if possible.

2.       The interface contains a huge number of constants with defined values. To reduce script size and gain a little bit performances I thought about pass directly the values instead of using the constants. Is this a bad Idea?



It's not a bad idea. The constants will not / can not change.

3.       GLSL optimization: Should we expect good optimization on the API/Driver level or would it better to use an optimizer on GLSL level? I am expecting that this would depend mostly on the driver on the target platform, right?



Like you said, that's up to the platform.


-Ralf
-----------------------------------------------------------
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
-----------------------------------------------------------




PS: I started a FAQ on the wiki.


http://www.khronos.org/webgl/wiki/FAQ


Feel free to suggest or add more entries.
-----------------------------------------------------------
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
-----------------------------------------------------------