3.0.0 beta (ZGE on Android)

Information and change log about the latest ZGameEditor release.

Moderator: Moderators

Post Reply
User avatar
Rado1
Posts: 775
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 »

VilleK wrote:Rado1: I've changed so that File.TargetArray also works when writing to files. I modified your test project to use this feature and now it works.
Wow! I like it. The produced files are smaller than 3ds or obj and are loading pretty fast. No need for runtime mesh loader implemented in ZGE or in external library. Really useful feature.
User avatar
Rado1
Posts: 775
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 »

Problem: Android version ignores MaterialTexture's TextureScale and TexCoords == Generated properties. TextureX and TextureY are working correctly. See the attached screenshots.

Is there any chance to make these properties working as on Windows, or is it a "feature" of OpenGL ES?
Attachments
screenshot
screenshot
scr.jpg (68.33 KiB) Viewed 26351 times
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hi Rado1,
Rado1 wrote:Is there any chance to make these properties working as on Windows, or is it a "feature" of OpenGL ES?
The glTexGen functions used by Generated TexCoords aren't supported by OpenGL ES. There's no "fallback" implemented either at the moment ( in fact, the functions are simply skipped on Android ). Thing is though, generated texture coordinates should only be used for shaderless old-skool reflection / transparency / shadow effects ..

K
User avatar
Rado1
Posts: 775
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 »

Kjell, thanks for explanation. I used generated texture coordinates as a simpler alternative to achieve the desired mapping. Nevermind, I recomputed texture coordinates for meshes and achieved the same result with model defined texture coordinates.

BTW some section of ZGE online help to explain differences for Android would help.
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski »

Also, the TexureWrapMode (mirror, clamp) functions do not work in ES. Is there another way to get those on Android? I have found both to be rather useful in various situations,. .

Adding a second texture in a ZGE Material normally gives the ability to use a transparency mask on the texture,. I use this in conjunction with glAlphaFunc() to do the levels in The Mine,. I can get the distance field rendering technique to work, however not with a second texture applied. (just started working on that though) Is the second texture of a Material just ignored as well?
iterationGAMES.com
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Here is an explanation on how OpenGL calculates the generated coordinates so maybe it can be emulated in an MeshExpression: http://www.opengl.org/wiki/Mathematics_of_glTexGen

I can't find any documentation that says GL_MIRRORED_REPEAT or texture scaling using the texture matrix isn't supported on GL ES. So it could be hardware specific if it works or not. Or it could require GL ES 2.0, which is difficult for ZGE to support because that means we must move to the new opengl model with all shaders and no fixed functionality.

The problem with using several textures is that there is currently no way in ZGE of specifying separate coordinates of the other textures. So at the moment you need generated coordinates to make the other textures show. We could add something to MeshExpression to allow writing to several set of coordinates. Or take another approach, suggestions are welcome. Ideally something that doesn't break backwards compatibility.
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hi guys,
VilleK wrote:I can't find any documentation that says GL_MIRRORED_REPEAT or texture scaling using the texture matrix isn't supported on GL ES.
The texture matrix is supported on ES 1.1, but GL_MIRRORED_REPEAT isn't ( only GL_CLAMP_TO_EDGE and GL_REPEAT are ).

http://www.khronos.org/opengles/sdk/1.1 ... ameter.xml
VilleK wrote:The problem with using several textures is that there is currently no way in ZGE of specifying separate coordinates of the other textures. So at the moment you need generated coordinates to make the other textures show. We could add something to MeshExpression to allow writing to several set of coordinates.
The easiest ( but worst? ) solution would be to add a additional HasTex2Coords / HasTex3Coords checkboxes to MeshExpression. A more flexible approach would be to add a Attributes node to a Mesh allowing to add additional attributes to the standard ones. Even more powerful would being able to define a exact vertex attribute specification, but not sure that can be implemented without breaking backwards compatibility.

K
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski »

I did a bit of looking around and indeed ES 2.0 seems to be the standard for all the nifty moble and compact devices,. I am wondering if you should fork the ZGE? Lock down the current features, and do a release 3.1 or 4 or whatever, and do a separate ES implementation? People seems to say that learning the fixed pipeline is a bit simpler, but that the newer version is inevitable, more powerful, and should be what we pursue.

For me the current feature set is amazing, and I will happily be developing PC and Android games using it for the foreseeable future. I am however also curious about the "all shader model". Perhaps implementing a node system (like the mesh/bitmap ones) for editing shaders would make this more usable for those of us that are less skilled in shader development. Or even just a great set of basic shader examples, that are extensible and integrated well with the engine's setup would be good. Just some thoughts about he future.
iterationGAMES.com
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hi jph,
jph_wacheski wrote:I did a bit of looking around and indeed ES 2.0 seems to be the standard for all the nifty moble and compact devices,. I am wondering if you should fork the ZGE?
No need to fork ZGE. A drop-down that lets you choose between a fixed ( ES 1.x ) and programmable ( ES 2.0 ) pipeline should be sufficient ... if needed at all, perhaps it's possible to build a Android apk that supports both ES 1.x and 2.0.
jph_wacheski wrote:Perhaps implementing a node system for editing shaders would make this more usable for those of us that are less skilled in shader development.
A node-based shader editor ( or any abstract layer on top of GLSL ) is actually the easiest way to support fixed-function features ( lights, fog and such ), as you can simply generate the entire shader source ( instead of having to inject ).
jph_wacheski wrote:For me the current feature set is amazing, and I will happily be developing PC and Android games using it for the foreseeable future. I am however also curious about the "all shader model".
You can already use the "all shader model" on PC .. simply make sure all your Material components use a Shader. But i'm sure you already knew that :wink:

K
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

The problem with supporting GL ES 2.0 model is that the fixed functionality is not available. This has the following consequences in ZGE:
- Cannot call the built in matrix operations glTranslate, glScale and glRotate so it will need to be replaced with matrix operations in ZGE
- No "default shader" so all materials must have a shader
- Shaders do no longer have the predefined names gl_Vertex etc so we must add a way in ZGE to pass custom vertex format. The same with the transformation matrix.

There is likely to be additional consequences that I haven't yet identified too. Since it is hard for me to evaluate how much work it is to make this adaption I hesitate to do so. Branching might not be such a bad idea after all, we could always merge it back into the main branch later if the adaption is successful. However I'm not yet convinced the gain is worth the effort.

It is annoying the fixed functionality in GL is deprecated because using it makes it much easier to get started with 3d-programming. Making an API harder to use is not progress.
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hej Ville,
VilleK wrote:Cannot call the built in matrix operations glTranslate, glScale and glRotate so it will need to be replaced with matrix operations in ZGE
You'll want to do this anyway. Currently a model matrix is "generated" using each of those functions individually ( rotate 3 times even ), which basically results in the creation of 5 individual matrices and 4 matrix multiplications .. while you can do this in one go ( without any matrix multiplications ) giving a significant performance gain. Plus if you cache the matrix in your Model class, you can re-use the result for other things ( hierarchy, collision etc. ).
VilleK wrote:Shaders do no longer have the predefined names gl_Vertex etc so we must add a way in ZGE to pass custom vertex format. The same with the transformation matrix.
The attribute specification is controlled by ( and can thus be deferred from ) the Mesh component. Simplest solution would be to automatically remove any "gl_" prefixes from vertex attributes and matrices in the shader source when building for ES 2.0.
VilleK wrote:Since it is hard for me to evaluate how much work it is to make this adaption I hesitate to do so.
It's not that bad really.

K
User avatar
jonaspm
Posts: 89
Joined: Fri Jul 06, 2012 3:51 pm
Contact:

Post by jonaspm »

Why not GLES 3.0? It is backwards compatible with 2.0 and has some nice improvements:

*multiple enhancements to the rendering pipeline to enable acceleration of advanced visual effects including: occlusion queries, transform feedback, instanced rendering and support for four or more rendering targets

*high quality ETC2 / EAC texture compression as a standard feature, eliminating the need for a different set of textures for each platform

*a new version of the GLSL ES shading language with full support for integer and 32-bit floating point operations;

*greatly enhanced texturing functionality including guaranteed support for floating point textures, 3D textures, depth textures, vertex textures, NPOT textures, R/RG textures, immutable textures, 2D array textures, swizzles, LOD and mip level clamps, seamless cube maps and sampler objects

*an extensive set of required, explicitly sized texture and render-buffer formats, reducing implementation variability and making it much easier to write portable applications.
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hi jonaspm,
jonaspm wrote:Why not GLES 3.0?
Because virtually nobody has a device that supports ES 3.0 at this point :)

K
User avatar
jonaspm
Posts: 89
Joined: Fri Jul 06, 2012 3:51 pm
Contact:

Post by jonaspm »

But when this feature is incluided, there will be a lot of devices :)
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hi jonaspm,
jonaspm wrote:But when this feature is incluided, there will be a lot of devices :)
Depends on when when is :wink: The first GPUs with ES 3.0 support were only released in the last few months. If you have a Nexus 7 or iPhone 5 ( or anything older ) you're out of luck.

K
Post Reply