Jump to content

3D Engines Comparison

Canardian

478 views

RankNameOpenGL SupportBasic Dynamic ShadowsFull Dynamic Shadows256+ Dynamic LightsRealtime GIOGG SoundsC/C++ SupportRealtime ScriptingSource Code IncludedEntity Based SystemLow End SupportHigh End SupportPhysicsOpenGL CommandsRealtime EditorCross-PlatformNetworkingPrice under $1000TotalScoreImportance151016141211332471117568091Leadwerks EngineYesYesYesYesNoYesYesYesNoYesNoYesYesYesYesNoYes200142Max3DYesYesYesYesNoYesYesNoYesYesNoYesYesYesNoYesNo0133CryENGINE 3NoYesYesYesYesYesYesYesYesNoNoYesYesNoYesNoYesNo124Unity ProYesYesNoNoNoYesNoYesNoNoYesYesYesYesYesYesYes1499115Xors3DNoYesYesYesNoYesYesYesNoYesYesYesYesNoNoNoNo100116Chrome 4NoYesYesYesNoYesYesYesYesNoNoYesYesNoYesNoYesNo117TorqueYesYesNoNoNoYesYesYesYesNoNoYesNoNoYesYesYes1000118Ogre3DYesYesNoNoNoYesYesNoYesNoYesYesNoNoYesYesNo0109EsenthelNoYesYesYesNoYesYesYesNoNoNoYesYesNoYesNoYes70001010IrrlichtYesYesNoNoNoYesYesNoYesNoYesYesNoNoNoYesYes01011Flow3DYesYesNoNoNoYesNoNoNoYesYesYesYesNoYesNoNo50912C4 StdYesYesNoNoNoNoYesNoYesNoNoYesNoNoYesYesYes3509133D Game Studio A7NoYesNoNoNoYesYesYesNoNoNoYesYesNoYesNoYes199/899914MiniB3DYesNoNoNoNoYesNoNoYesYesYesNoNoYesNoYesYes80915Ninfa3DYesYesNoNoNoYesNoNoYesNoYesYesYesNoNoNoNo0816Truevision3DNoYesYesYesNoNoYesNoNoYesNoYesYesNoNoNoNo150817Nuclear FusionNoNoNoNoNoYesYesNoYesYesYesNoNoNoNoNoYes59718Blitz3D SDKNoNoNoNoNoYesYesNoNoYesYesNoNoNoNoNoYes100619Blitz3DNoNoNoNoNoYesNoNoNoYesYesNoNoNoNoNoYes1005More rows and columns still coming... You can suggest what other engines you want on the list, but please provide the column infos, as I own/know only these engines. I'm more interested in higher rank engines though, as there are tons of lower ranks engines on the market, but I will still add low rank engines too, if I got all info for them.Explanation of the columns and their relevance:OpenGL Support: This feature is important for people who want to make cross-platform 3D development.Basic Dynamic Shadows: Basic or incompletely implemented Dynamic Shadows. Some engines don't have point light shadows, some have only stencil shadows.Full Dynamic Shadows: This means that all lights cast realtime shadows on all 3D objects, including self-shadowing, which means that a 3D object casts also shadows on it's own surfaces, and not only on other surrounding 3D objects. Also PoM shadows (=shadows from 3D textures) are needed to qualify as a Full Dynamic Shadows engine.256+ Dynamic Lights: This is only possibe with deferred rendering capable engines. The alternative to deferred rendering is forward rendering, which allows only around 128 dynamic lights (using a 128 buffers hack) due to color overburn and too low performance if you go above that. However, in most cases only 4 or 8 dynamic lights are used in forward rendering engines.Realtime GI: Realtime Global Illumination means light bounces, color bleeding and specular effects in realtime.OGG Sounds: The Vorbis OGG audio compression format allows high quality sounds at low file sizes and streaming. Also licensing issues are important for 3D application development, where the OGG format provides a GPL free license.C/C++ Support: The C and C++ programming languages have been the de facto standard for industrial computer software engineering since 1972 © and 1978 (C++). The support for external standard libraries is huge, and thus saves companies a lot of time and money when developing computer software. They create also the fastest applications.Realtime Scripting: The engine can be controlled using a script language, and scripts can be changed on the fly.Source Code Included: The engine comes with its source code. Many engines have also a seperate Source Code license, which can be very expensive.Entity Based System: This means that everything in the 3D world is a 3D Entity (sounds, cameras, models, pivots, lights, emitters, etc...), which can be controlled with the same commands like MoveEntity, ScaleEntity, TurnEntity, HideEntity, ShowEntity, etc...Entity Based Systems provide an easy learning curve, and powerful operations with simple commands, since no academic 3D matrix math is needed to be learned by the user.Alternatives to an Entity Based System is a Node Based System or a Tree Based System.Low End Support: This means basically that the engine can run with any existing graphics card.High End Support: This means that the engine supports modern AAA 3D technologies, and requires a SM3/SM4 capable graphics card.Physics: The engine has physics built-in and integrated.OpenGL Commands: The user can freely program in OpenGL language on top of the engine's 3D rendering. This is normally needed only for special purposes, like for example drawing 3D lines in the 3D space. Usually the engine renders 3D graphics much faster due to its internal optimizations.Realtime Editor: The engine has a native or 3rd party with plug-ins 3D Editor which shows the results of editing in realtime.Cross-Platform: The engine runs natively at least under MacOSX or Linux.Price under $1000: A point is given if the engine costs $1000 or less.

 

Source



0 Comments


Recommended Comments

There are no comments to display.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Blog Entries

    • By Josh in Josh's Dev Blog 2
      The Leadwerks 5 beta will soon be updated with particle emitters and an example particle system plugin. Previously, I showed some impressive results with physically interactive particles that collide with and exert forces on the environment. I decided to use the plugin system for controlling particle behavior, as this offers the best performance and can be run on the physics thread. 
      A particle system plugin uses some predefined structures and functions to modify the behavior of particles when they are emitted or as they are updated. This allows for unlimited features to be added to the particle system, because anything you want can be added with a plugin. A system for sending settings to the plugin will be implemented in the future so you can adjust the plugin settings and see the results. The default particle settings and features will probably stay pretty barebones and I will just use the plugin system to add any advanced functionality since it is so flexible.
      void EmitParticle(ParticleModifier* mod, ParticleSystem* particlesystem, Particle* particle) { if (mod->emissionshape == EMISSION_SHAPE_BOX) { particle->position[0] = Random(-mod->area[0], mod->area[0]); particle->position[1] = Random(-mod->area[1], mod->area[1]); particle->position[2] = Random(-mod->area[2], mod->area[2]); } else if (mod->emissionshape == EMISSION_SHAPE_CYLINDER) { particle->position[0] = Random(-mod->area[0], mod->area[0]); particle->position[1] = Random(-mod->area[1], mod->area[1]); particle->position[2] = Random(-mod->area[2], mod->area[2]); auto l = sqrt(particle->position[0] * particle->position[0] + particle->position[1] * particle->position[1] + particle->position[2] * particle->position[2]); if (l > 0.0f) { particle->position[0] /= l; particle->position[1] /= l; particle->position[2] /= l; } } particle->position[0] += particlesystem->matrix[12]; particle->position[1] += particlesystem->matrix[13]; particle->position[2] += particlesystem->matrix[14]; } There are three other new Lua examples included. Coroutines.lua shows how a sequence of actions can be added to an entity before the game starts, and the actions will be executed in order:
      --Create model local model = CreateBox(world) --Add some behaviors to be executed in order model:AddCoroutine(MoveToPoint, Vec3(3,0,0), 2) model:AddCoroutine(MoveToPoint, Vec3(-3,0,0), 2) model:AddCoroutine(MoveToPoint, Vec3(0,0,0), 2) --Main loop while window:Closed() == false do world:Update() world:Render(framebuffer) end This is great for setting up cut scenes or other sequences of events.
      An example showing how to enable tessellation is also included. Tessellation is now a per-camera setting.
      camera:SetTessellation(10) The number you input is the size in pixels of the tessellated primitives. Use zero to disable tessellation. Tessellation is disabled by default on all cameras.
      Finally, an example showing how to use a texture loader plugin is included. All you have to do is load the plugin and after that textures can be loaded in VTF format:
      local vtfloader = LoadPlugin("Plugins/VTF.dll") local tex = LoadTexture("Materials/wall01.vtf")  
    • By Josh in Josh's Dev Blog 4
      I made some changes to the design of the particle system. I am less concerned with the exact behavior of particles as they move around and move interested right now in building a system with good performance and deep physics interactions. Although I want particle behavior to be customizable, I don't think scripts are the right tool for the job. C++ plugins are better suited for this for two reasons.
      C++ is much faster, and particles are a system that will make heavy use of that. Lua scripts can't be run on separate threads. In Leadwerks Engine 4 we have basic particle collisions, but I wanted something more interactive in the new system. I move the particle update code into the physics thread. I implemented collision as well as the ability for particles to exert forces on other objects. Here's what happens when some slow-moving smoke particles interact with a scene: The lower platform rotates freely while the upper platform is motorized.
      When the particle velocity is increase they start to behave like a stream of water:
      Best of all, the speed is surprisingly fast. 4000 particles with collision update in just 2 milliseconds. The code scales well across cores so if you have a lot of CPU cores simulations with 100,000 particles are possible.
      Right now particles are processed in the physics thread, and get sent to the rendering thread for display, but right now the main thread actually never sees the individual particles.
      This is fast enough I think particles will default to full physics. Instead of just being a dumb visual effect we are going to have fully interactive fluids and gases. Flamethrowers can fill a room with fire and it will creep around corners to fill a space.
    • By Josh in Josh's Dev Blog 7
      For finer control over what 2D elements appear on what camera, I have implemented a system of "Sprite Layers". Here's how it works:
      A sprite layer is created in a world. Sprites are created in a layer. Layers are attached to a camera (in the same world). The reason the sprite layer is linked to the world is because the render tweening operates on a per-world basis, and it works with the sprite system just like the entity system. In fact, the rendering thread uses the same RenderNode class for both.
      I have basic GUI functionality working now. A GUI can be created directly on a window and use the OS drawing commands, or it can be created on a sprite layer and rendered with 3D graphics. The first method is how I plan to make the new editor user interface, while the second is quite flexible. The most common usage will be to create a sprite layer, attach it to the main camera, and add a GUI to appear in-game. However, you can just as easily attach a sprite layer to a camera that has a texture render target, and make the GUI appear in-game on a panel in 3D. Because of these different usages, you must manually insert events like mouse movements into the GUI in order for it to process them:
      while true do local event = GetEvent() if event.id == EVENT_NONE then break end if event.id == EVENT_MOUSE_DOWN or event.id == EVENT_MOUSE_MOVE or event.id == EVENT_MOUSE_UP or event.id == EVENT_KEY_DOWN or event.id == EVENT_KEY_UP then gui:ProcessEvent(event) end end You could also input your own events from the mouse position to create interactive surfaces, like in games like DOOM and Soma. Or you can render the GUI to a texture and interact with it by feeding in input from VR controllers.

      Because the new 2D drawing system uses persistent objects instead of drawing commands the code to display elements has changed quite a lot. Here is my current button script. I implemented a system of abstract GUI "rectangles" the script can create and modify. If the GUI is attached to a sprite layer these get translated into sprites, and if it is attached directly to a window they get translated into system drawing commands. Note that the AddTextRect doesn't even allow you to access the widget text directly because the widget text is stored in a wstring, which supports Unicode characters but is not supported by Lua.
      --Default values widget.pushed=false widget.hovered=false widget.textindent=4 widget.checkboxsize=14 widget.checkboxindent=5 widget.radius=3 widget.textcolor = Vec4(1,1,1,1) widget.bordercolor = Vec4(0,0,0,0) widget.hoverbordercolor = Vec4(51/255,151/255,1) widget.backgroundcolor = Vec4(0.2,0.2,0.2,1) function widget:MouseEnter(x,y) self.hovered = true self:Redraw() end function widget:MouseLeave(x,y) self.hovered = false self:Redraw() end function widget:MouseDown(button,x,y) if button == MOUSE_LEFT then self.pushed=true self:Redraw() end end function widget:MouseUp(button,x,y) if button == MOUSE_LEFT then self.pushed = false if self.hovered then EmitEvent(EVENT_WIDGET_ACTION,self) end self:Redraw() end end function widget:OK() EmitEvent(EVENT_WIDGET_ACTION,self) end function widget:KeyDown(keycode) if keycode == KEY_ENTER then EmitEvent(EVENT_WIDGET_ACTION,self) self:Redraw() end end function widget:Start() --Background self:AddRect(self.position, self.size, self.backgroundcolor, false, self.radius) --Border if self.hovered == true then self:AddRect(self.position, self.size, self.hoverbordercolor, true, self.radius) else self:AddRect(self.position, self.size, self.bordercolor, true, self.radius) end --Text if self.pushed == true then self:AddTextRect(self.position + iVec2(1,1), self.size, self.textcolor, TEXT_CENTER + TEXT_MIDDLE) else self:AddTextRect(self.position, self.size, self.textcolor, TEXT_CENTER + TEXT_MIDDLE) end end function widget:Draw() --Update position and size self.primitives[1].position = self.position self.primitives[1].size = self.size self.primitives[2].position = self.position self.primitives[2].size = self.size self.primitives[3].size = self.size --Update the border color based on the current hover state if self.hovered == true then self.primitives[2].color = self.hoverbordercolor else self.primitives[2].color = self.bordercolor end --Offset the text when button is pressed if self.pushed == true then self.primitives[3].position = self.position + iVec2(1,1) else self.primitives[3].position = self.position end end This is arguably harder to use than the Leadwerks 4 system, but it gives you advanced capabilities and better performance that the previous design did not allow.
×
×
  • Create New...