Ideas

From Yage3D Wiki

This is a rough list of ideas and possible/probable upcoming todos:

Contents 1 Reorganization of Rendering System 2 Other 3 Older 4 Really Old Ideas

[edit] Reorganization of Rendering System

Yage's rendering should be reorganized into a two-tier system.

• The lower tier will provide functions for binding a material, texture, shader, light, or model.
  • It will be state dependent,
  • but it will implement GraphicsAPI which will allow its caller to not care if it uses OpenGL or something else internally.
  • When data is specified, it will automatically upload it to OpenGL when bound, if not already uplaoded.
• The higher tier will be completely stateless. You give it a camera and a rendering target, and it renders what the camera sees to the target
  • Or a Surface and a target.
  • This tier will also be graphics API agnostic.

[edit] Other

• Drop SDL SDL_Image and Ogg/Vorbis - replace with native calls to Win32 and GLX, and use ffmpeg for image and audio loading
• Allow bindRenderTarget to specify viewport coordinates in a percent range from 0 to 1
• Create a class to map render target buffers, so color buffer can be rendered to depth buffer, or stencil, etc.
• Provide an optional top level catch, so exception messages can be written to the console or log file

[edit] Older

• Merge TerrainNode and GraphNode into GeoNode
  • Would allow loading a terrain from a heightmap or a 3D graphing callback function.
  • Doesn't have to be relatively flat, like most terrain nodes, could be spherical or any other deformed grid shape.
  • Could use geomipmapping.
  • A special colored heightmap could be used to store advanced shapes, where the x,y coordinates of the image are input into the grid, and the r,g,b color at that pixel are 3d coordinates of that vertex.
• Separate out a Window class from Device, for creating and destroying windows as necessary.
  • What about sharing opengl contects in SDL?
• Add support for VisibleNode rendering attributes, as Panda3D supports: http://panda3d.org/wiki/index.php/List_of_All_Attributes. Rendering attributes are inherited by all children unless overridden. Perhaps it could be similar to the Style used to customize Surfaces.
• Support built-in performance analysis tools?
  • Allow a DynamicCamera class that adjusts rendering settings to meet a required framerate?
• Divide off a lens class from Camera? (see http://panda3d.org/wiki/index.php/Lenses_and_Field_of_View)
• Allow Node's (and Surfaces?) onUpdate function to use stack threads with yeild?
• Is it worth writing an OpenGL state manager to minimize state changes, or is this handled already by video drivers?

joe-coder: is it good for performance to write a wrapper to handle and minimize opengl state changes, or is this usually handled by the driver?
RTFM_FTW: yes its good
joe-coder: i iterate over items to render, different ones have texturing, lighting, borders, etc. enabled or disabled.
RTFM_FTW: one should always attempt to minimize and group state changes
RTFM_FTW: caching state on the client side is another (related) step
joe-coder: why isn't this handled by the driver--seems like an eazy optimzation.
joe-coder: let's forget about changing rendering order for the moment.
joe-coder: but for example just rendering 3 items, glEnable(GL_T..2D);  draw1(); glDisable(GL_T..2d);  glEnable(GL_T..2D);  draw2(); glDisable(GL_T..2d);  glEnable(GL_T..2D);  draw3(); glDisable(GL_T..2d);
RTFM_FTW: why would the driver automatically cache / optimize the state order for your application?
joe-coder: in that example, the driver could eliminate the disable/enable between drawing calls.
RTFM_FTW: considering that the driver (in the most general case) knows very little about what you require
RTFM_FTW: umm not necessarily
joe-coder: all it would have to do is cache changes and not apply state until an actual rendering call is made.
joe-coder: i guess there's also an advantage to having the state ready before the rendering call is made.
joe-coder: makes sense now, thanks.
RTFM_FTW: in any case the driver is likely to cache certain (internal) aspects of state (for example shader programs required for a certain encountered state option) but this is implementation dependent
RTFM_FTW: and in all cases you *still* have to call into the API in order to analyze this
RTFM_FTW: and that in and of itself isn't free
RTFM_FTW: even setting a single flag (which ends up going nowhere) isn't free when it might require multiple subroutine calls to resolve
joe-coder: in a state manager, couldn't you query the state once and then track it in application memory as it changes (assuming all state change calls go through the state manager)
RTFM_FTW: and on that note *never* having to call into the API is always going to be the best option for performance :D
RTFM_FTW: yep you could
RTFM_FTW: such a system is what I was hinting at with my "state caching" comment
RTFM_FTW: that alone should significantly decrease the number of API calls you require
RTFM_FTW: during rendering
joe-coder: and would also keep my code cleaner if I add push and pop to that state manager.

• Study XBMC for ideas for a default gui skin (since it's so well designed).
• Make logging consistent and typed.
• Run input processing in its own thread separate from scene updates and rendering.
• Allow Nodes and Surfaces to use Fibers for updates
  • See: http://team0xf.com/conference/fibers.pdf
  • Requires a switch to Tango. Switch to D2 or Tango? (both eventually)

[edit] Really Old Ideas

• Add a max lights setting per material
• Add a setting for min or max mipmap level per texture at the material level
• Add boolean set operations to the Resource manager, to load all resources from a new level and free only those that aren't part of that set.
• Break apart Device.init() into different subsystems, and reduce dependance on dll's to only when they're actually used.
• A sensor node that checks for certain events (brightness, velocity, distance, etc.) and calls callback functions when certain events occur. (any node can do this in its update function).
• Use axis sorting to tell what lights affect what nodes (instead of n*m distance check). Will break down for lights with large radius?
• Use dx cross dy to calculate normals for parametric graphnodes.