Page 1 of 3 123 LastLast
Results 1 to 10 of 29

Thread: Abstracting Graphical APIs

  1. #1

    Abstracting Graphical APIs

    Hello everyone,

    Recently I've been thinking on how to achieve such thing as creating abstract graphical api for rendering 3d graphics, which on it's side could be implemented using Direct3D11, Direct3D9 or OpenGL3.3. It is very possible that I don't start doing it at all, but I'm still very curious for different and efficient approaches on achieving this.

    I guess since most of you here are currently writing on the community game engine, you are faced to similar challenges.

    Here are my few thoughts, and I'm very interested is someone with experience on similar things share their advices.

    The first question I face is -what would be the level on which the api works (higher or lower). I.e. should I design the API to allow the user to draw primitives in BeginDraw/EndDraw style. Or should I create abstract class for a Meshes or Models and for Textures and Materials, which will be implemented in different ways for the different graphic providers then have a Context object to render Mesh objects? Should the mesh's per-vertex data (position, normals, etc) be predefined in a list of different variants or the user should be able to implement their descendant of the Mesh class.
    - Maybe a good approach is to create my abstract api on the level similar to the fixed-function pipelines' of the legacy DirectX and OpenGL versions (but implemented via shaders)?
    - For now I think it is a good idea to create abstract Context class, Mesh, Texture, Shader/Material, Model(group of meshes with materials), Camera class (which should provide functionality to easy manipulate the camera and feed the matrices to the shaders).
    - Maybe support some kind of Scene Graph, where the user can add hyerarchy of Models, and light source objects

    Another question is - What about shaders?
    - One solution would be just not to allow the api user to create their own shaders and implement(hardcode) different rendering scenarios (for example, flat shading, blin-phong, blin-phong with bump mapping, shadow projection, and others) - lets say i have an abstract Context object, (lets say TGALContext), which have a predefined enum of scenarios, and I call TGALContext.SetScenario(csBlinPhongNormalMapping) or something like this, which internally would use particular group of shaders to render in that particular way.
    - I have read that some engines (like Ogre3D) have some kind of their material meta language, which can be translated either to GLSL or HLSL depending on the graphic provider used.
    - Another thing I've read is that I can make a material description file, (maybe XML), which describes the inputs of the shader and the outputs, followed by implementation in both HLSL and GLSL for Vertex and Fragment shaders (in both langagues using the same data types as inputs). So when the API user writes shaders, they should write such Material Description file containing implementation both in GLSL and HLSL.

    Have someone really implemented such kind of (3d) graphic abstraction in their Pascal engines? And what, do you think, is the best way to do it?

    P.S: Sorry for the bad organization of the post and my not so good english
    Last edited by Anton; 27-01-2015 at 01:43 PM.

  2. #2
    Seems that https://github.com/bkaradzic/bgfx does something close to what your goal is, so you may find some inspiration there perhaps. As for API: provide low level functions and build the high level stuff on it, so it would be optional to use?

  3. #3
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    In terms of API level I'd recommend you abstract high rather than for low level functions. In terms of 3D API's it's really only DirectX + OpenGL to choose from right now but you can't garuntee that all future versions of those API's will match previous versions on a fundamental basic level of operation. The changes we see between OpenGL1/2 and 3+, droppping of immediate mode etc are evidence that if you're abstracting an API to be future proof, you want to go as high as possible.

    Also ask yourself if you really want to support DirectX at all with Freepascal/Delphi. We're unlikely to see Xbox support any time soon and OpenGL exists on the windows platform too, so you get a fully capable 3D API on all operating systems you can potentially target with your language.

    Designing a structure/Abstracting between different versions of OpenGL is far simpler than between DirectX/OpenGL as there's enough stuff that's pretty much the same across all of GL/GLES to make it so.

    if you want to target android/ios and desktops then you'll need some form of abstraction between GL/GLES differences.


    --

    If you are going DirectX + OpenGL then the question of shaders, either an XML file or just a file naming convention to store both HLSL and GLSL shaders is the best approach. The abstracted shader language of the ogre engine is a really nice thing but it took a long time to create, it's very complex and very hard to produce optimal shaders generically.

    Best keep things simple. So your users will have to write a GLSL and a HLSL shader, no big deal. Other than a few keywords/functions and the general structure, you can reuse pretty much all of your shader code. They'd have to learn a meta-language if you created one anyway, save yourself tons of work and let them spend another 30 minutes writing shaders.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  4. #4
    I have read some articles of other people trying to achieve similar thing, and it seems the lower the level of the API is, the harder it gets to design it. And for a hobby project, it doesn't worth the effort. On the other hand, a higher level API would be much easier to design, but it will seriously limit the potential scenarios it can handle.

    So for now I would avoid doing such kind of abstraction layer and stick to either DirectX or OpenGL for each application, or maybe use SDL.

    Quote Originally Posted by imcold
    Seems that https://github.com/bkaradzic/bgfx does something close to what your goal is, so you may find some inspiration there perhaps. As for API: provide low level functions and build the high level stuff on it, so it would be optional to use?
    This looks very interesting, I'll definately take a look at how it is designed.

    Quote Originally Posted by phibermon
    Also ask yourself if you really want to support DirectX at all with Freepascal/Delphi. We're unlikely to see Xbox support any time soon and OpenGL exists on the windows platform too, so you get a fully capable 3D API on all operating systems you can potentially target with your language.
    In this case the only platforms which doesn't support OpenGL seems to be XBox and WindowsRT, but I'm not interested in those anyway.

    I'm interested to know are there big performance differences between OpenGL and DirectX on Windows, I have read some articles stating the Direct3D would perform better on Windows platforms?

  5. #5
    Quote Originally Posted by Anton View Post
    I'm interested to know are there big performance differences between OpenGL and DirectX on Windows, I have read some articles stating the Direct3D would perform better on Windows platforms?
    From my expirience that largely depends on graphical drivers. One think that you definitly want to avoid is using graphical drivers that are installed by windows itself.
    Always instal official drivers from your graphic card manufactuer becouse drivers that come with windows often don't provide full functionality and in case of some older graphics card they even limit OpenGL to OpenGL 1 compatiblility even thou the graphic card itself does full support OpenGL 2.
    I'm not sure how it is this with newest graphics cards becouse now I always install official drivers right after installing chipsets drivers for motherboard. Now in case of older computers and ATI graphics card it is also recomended to install sound drivers before graphical drivers especiall for graphics card that already support HDMI so that graphics drivers can corectly interface with sound drivers (I had encountered severl dificulties when this didn't happen). But on newer AMD graphics card this is no longer necessary as they have full sound card support integrated right into them and therefore no longer require your computer to have other sound card.

    As far as raw performance goes I have rarely seen any significant diferences when comparing benchmarks between DirectX and OpenGL. And whenever DirectX actually did give higher performance running of DirectX benchmark itself utilized CPU much more than the OpenGL benchmark therefore I can conclude that the aditional performance of DirectX test was due to aditionaly utilizing CPU for certain graphical processing. But in games that probably would not give you much performance boost, infact it could result in worse performasnce becouse it would eat up CPU performance that might be necessry for your game logic.

  6. #6
    Hi Anton,

    You should take a look of Embarcadero engineer work, on FMX : They done exacly that : We can discuss on the good or the bad of the implemention end/or architecture, but their solution is here and available now.

    Their goal was simple : When you create a 3d Component, the drawing must :
    - Give the same results on OpenGL (OSX) DirectX (Win) and OpenGLES (Mobile)
    - Must permit low level vertex access.
    - Must take care of Shaders

    The API and class tree is, in my point of view, pretty good, even if the VertexData access and Index access is not very weel design : We are more near DirectX than OGL. :/

    Cheers,

    Vincent

  7. #7
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    The design chosen for FMX is totally unsuitable to base a game engine on in my opinion, it's an abstraction too far if you're looking to implement rendering techniques commonly used in game engines - you'll hit wall after wall. If you only use Delphi and you don't care about lighting, shadows, deferred rendering and anything else that you need to write custom shaders for then go right ahead but bare in mind that FMX is designed *only* to provide a hardware accelerated GUI across windows/osx/mobile to allow smooth animations etc.

    To the best of my knowledge you have no direct access to the underlying graphics API and no control over what valuable graphics memory FMX uses, no control over multi-sampling and other OS specifics, where in the pipeline FMX renders, how it renders etc

    For these reasons an engine co-existing with FMX is a world of compromise - it just wasn't designed with game developers in mind and that's fine because FMX's target audience are app developers who either don't know how or want to save time in creating hardware accelerated animation effects, something FMX does well enough to make it an attractive option for some.

    There are plenty of existing 3D engines and of course you can write your own and if you want a funky GUI then it should be one designed to 'plug-in' in a generic manner to *any* rendering paradigm rather than one that tries to *be* the rendering paradigm.

    My own JUI does this (designed from the ground up to be the UI of a 2D/3D hardware engine) and you'll find a number of other GUI's in the C++ world that you can use as dynamic libs if you're looking for a GUI to use with your engine.

    But from the point of view of an experienced 3D engine developer? Steer clear of FMX! it's a very poor app-centric design that makes little to no concessions for shared use of the hardware.

    Ogre3D is your friend. It's arguably the best multi-purpose 3D engine in existence (only being beaten by engines such as Unreal/Tech when it comes to first person, high density BSP style mesh / texture games)

    Unity is popular but only because it does all the hard work for you, it doesn't actually do that hard work in an optimal way that can contend with technical engines such as Ogre.

    --

    But as stated, I'd just forget about DirectX if I were you. OpenGL is just as fast when used correctly and has a more logical design that's industry standard for everybody outside of Microsoft. The PS3 and PS4 both use GL so I'd say its credentials are good.

    The only reason DirectX support would ever be considered worth the time and effort to add (to an engine that also targets non Microsoft platforms) is that certain older built-in laptop graphics adapters have crappy OpenGL support. Nothing to do with the API and everything to do with the drivers. If you're only targeting windows and are absolutely sure you never want to operate outside of the Microsoft eco-system then DirectX is a logical choice plus should you also develop in C++/.NET and wish to target the Xbox or Windows mobile platforms then it's not wasted knowledge.

    However anything from Nivida/AMD is fine with OpenGL as are Intel chips from the HD3000 onward, the days of poor OpenGL support in drivers are long gone.

    For WindowsRT support you can use a lib that converts OpenGL calls to DirectX (https://code.google.com/p/angleproject/) (and you can't yet target WindowsRT with any of the Object Pascal Compilers plus it'll all change again with Windows 10) and you can totally forget about Xbox support for non-microsoft compilers outside of the hacking scene.

    Don't waste your time basically, target OpenGL and have fun developing your engine rather than spending 80% of your time hacking away at a working abstraction between two API's for no benefit.
    Last edited by phibermon; 30-01-2015 at 06:36 PM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  8. #8
    Wow, cool down man

    I ask to Anton to see FMX because FMX implements a real abstraction of underlying hardware for graphics. And I said that we can discuss about the bad and the good, but it exists and available. I add this sentence justly to avoid the kind of post you do.

    Everyone here know that FMX is not a game engine, and it is even write in the Embarcadero's documentation. The question was not to use FMX as is, for Anton, but see how it is done, and get ideas.
    And Yes, you can access to the basic layer, throught FMX.Context.DX11, FMX.Context.GLES,FMX.Context.GLES.Ios and so on.

    When Anton said "I want to try to put in my engine a well design abstraction layer" you heard "I want to make a powerfull 3d engine"
    --> WTF ??

    Frankly, I'm tired about that everytime we said the word "FMX" in Pascal community, it will unchain a curious angry. A bit of frustrating ?


    Anton, to teach something, do not "Steer clear of" everything that could open your mind a give you a chance to choose.

    cheers,

  9. #9
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    I don't work for Embarcadero, my interests are in sharing knowledge and helping people to create what they want to create using the best possible tools available - not just the ones belonging to a single company.

    I know I spoke mainly of game engines but I'm advising to ignore FMX specifically on abstraction grounds - it's closed source, the user will learn nothing. The general process of API abstraction can be learned from thousands of different sources, studying a closed source API when there's much better and open source examples to study is pointless. After all this site is called pascal *game* development and the user it talking about 3D API's so of course we're talking in the context of 3D game engines. So yes I heard "I want to make a 3D rendering engine" and not "I want to draw buttons on propitiatory platforms". They are two very different goals and the abstractions required are totally different.

    FMX is a poor design even when cited as an example of abstraction so I wonder why you've chosen to mention it at all?

    Frankly, I'm tired of Embarcadero employees recommending unsuitable Delphi features as if they were perfect for games. FMX may make use of 3D API's but don't be tempted to confuse FMX as suitable for game development just because it does. My lawnmower uses petrol, it's not suitable for the race track.

    Recommending somebody dedicate their passion to your product just to shift units is immoral. It is their future in game development, not your advertising platform. The compiler is suitable for game development, the IDE is suitable for development in general and indeed many of the components could be useful as well (for game development, especially if you want to create database driven servers) but FMX out of everything Delphi has to offer is the one thing that definitely is *not* suitable for game development. Not in direct use or as an example of 3D API abstraction.

    Just to be clear : you can use Direct3D and OpenGL in Delphi without FMX. I'm not sure if that's true on the mobile platforms however but there's always Freepascal.
    Last edited by phibermon; 30-01-2015 at 10:41 PM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  10. #10
    Thank you all for you answers.

    If I choose for myself, I'll definately go with OpenGL, but when I work on projects which are not for myself, I'm not the one making the decision, so I thought such kind of abstraction layer would be useful since it accomplishes the requirements and in the same time it will be beneficiant since it will provide a potential to extend to other graphic apis.

    When Anton said "I want to try to put in my engine a well design abstraction layer" you heard "I want to make a powerfull 3d engine"
    Mostly my aim was for a general purpose 3D rendering abstract api.
    But to make it the right way seems very complex. So, I have given up the idea for now. Yet the topic is still interesting for me.

    Here are some posts I found interesting:
    - http://www.gamedev.net/topic/640055-...-to-rendering/
    - http://gamedev.stackexchange.com/que...ring-component
    - http://www.gamedev.net/topic/649416-...tx-opengl-etc/

Page 1 of 3 123 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •