Jump to content
  • Advertisement
Sign in to follow this  
davll

OpenGL iAztecGL - lightweight Next-Gen Graphic Engine

This topic is 3121 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, guy. It is the first thread I've opened. Recently, I've developed a project "iAztecGL". It is a light-weight Next-Gen Graphic Engine featuring flexible shader-material system. Currently, it can run on Mac OS X v10.6, and it is possible to be ported to Windows, PS3, Xbox360, and Linux. (For Graphic API: OpenGL, DirectX 9.0c, 10(Windows, Xbox360)), libGCM(PS3)) The source is licensed with MIT, and I will update googleCode later. I've solved these issues: 1) The dependence of Vertex Input Layout and Vertex Shader 2) The difference in shader constants (They were split into two groups: Global --> For among shaders, Local --> For owner shader) 3) Vertex input layout can be mapped to the setting of vertex shaders 4) Shader parameters are Cg-style However, I encountered some problems: One of them is Material. Many graphic engine, OGRE for example, can define custom multi-pass rendering, and render states per pass. But how to define lights after the scene changed? Because every material has its own vertex format and it might use vertex blending. However, solid materials don't need vertex blending. Thus, if Vertex Shader and Pixel Shader are packed in the class GPUProgram (due to GLSL), it will cost space and time. so I got some solutions to the problem: 1) Abandon GLSL, and split GPUProgram into GPUShaders 2) Move these rendering passes to outside of materials, as fixed-line. 3) Move the definition of lights to materials, and materials must offer several versions of different types of lights After all, these solutions are not perfect. Do anyone have idea to share?

Share this post


Link to post
Share on other sites
Advertisement
GLSL will cost space and time?you mean combination explosion?

Use deferred lighting or light prepass,then you can decoupling light from the object shader.

You can use a script material,export the engine function to script,then write the code in the script,don't just configuration like ogre.
You can get the most flexible than configuration type script.For example,if you want you can add a HDR effect and don't need to change the engine code.You can also write the hdr code in the engine,and in the script call it.

Share this post


Link to post
Share on other sites
1. I think GLSL will cost the space and time since they might share the same vertex shader. According to ARB/shader_objects, the storages of uniforms are bundled with program objects.
Anyway, I've never remove GLSL support for now.

2. Deferred lighting is a good idea, I think it can come with SSAO.
(However, it is hard to implement on XBox360 :P)
But I don't know anything about light prepass, can you explain more?

3. I almost misunderstood what you are meaning. Maybe using script-based material (Python, for example) can be more flexible, but there will be performance issues. Unlike GOAL/Data Compiler by NaughtyDog, most of the script languages are performed by interpreter. I think script language is not suitable to 60-frames-per-second-needed works.
But your idea is excellent, I think it can solve some portability issues. (such as XBox360 have to split the screen into two pieces in order to draw 720p screen.)

Thanks for your response.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!