Jump to content

  • Log In with Google      Sign In   
  • Create Account


An engine above a game engine

  • You cannot reply to this topic
2 replies to this topic

#1 sanmk4890   Members   -  Reputation: 116

Like
0Likes
Like

Posted 02 July 2014 - 01:30 AM

I want to make a 3d modelling engine for browsers. That is , a set of libraries that other developers can use to make 3d modelling software that run on browsers. This modelling engine will help achieve tasks specific to object modelling and exporting it (in browsers)

 

I thought of using existing 3d game engines to build this modelling engine, because it'd make my task easier. Existing 3d engines already exploit WebGL to the fullest, so if I use them I won't be losing out on any WebGL feature. But the key thing is, it makes development much quicker and easier (rather than working on WebGL directly)

 

So in a layered architecture way of representing: 

(1st) Lowest Layer : Web GL

2nd Level Layer : Existing 3d game engine

3rd Level Layer : My 3d modelling engine

4th Level : Products/Software that use the 3rd layer (the modelling engine)

 

Is that a reasonable/smart decision? Or should I just make my engine work directly above Web GL?



Sponsor:

#2 AgentC   Members   -  Reputation: 1222

Like
1Likes
Like

Posted 02 July 2014 - 03:32 PM

In general, when a good, ready-made library exists for a task, it's wise to use it to save time on development, just like you said.

 

However, you must be careful when evaluating the 3D libraries (Three.js probably being the most prominent). Are they actually as feature-rich and mature as they may seem on first glance? In your specific task, do they actually help, or do they rather limit you by forcing their own abstractions onto you, which may be more complex than those defined by WebGL itself? A modelling application is not a typical use case for a (game-like) 3D library, that is usually geared toward displaying pre-existing, mostly static content. That's not a deal-breaker though, as usually 3D libraries also provide some kind of API for arbitrary runtime modification of geometry. Whether they do that particularly smartly or not doesn't matter (performance-wise) before the scenes get complex (thousands of objects, millions of vertices..)

 

Also, when you're talking of a layered approach such that other developers should be using your modelling engine, then you'll have to learn the 3D engine you choose extremely well to inspire confidence in them, and to be able to solve problems that may occur in any of the layers. If you write the WebGL interfacing yourself, you'll (hopefully) become familiar with the potential issues earlier and gain a deeper understanding.

 

Another example: in the open source engine I've started, SDL is used for multiplatform windowing, audio & input. It becomes sort of a "black box" for those tasks, and if there's a complex enough problem on some of the supported platforms, I may not know enough of that platform and SDL internals to successfully solve that problem. Well, that's not such a big deal, as the engine's MIT licensed and the license disclaims all fitness for any purpose, but it'd be different if it was a product with a price tag...


Every time you add a boolean member variable, God kills a kitten. Every time you create a Manager class, God kills a kitten. Every time you create a Singleton...

Urho3D (engine)  Hessian (C64 game project)


#3 sanmk4890   Members   -  Reputation: 116

Like
0Likes
Like

Posted 03 July 2014 - 03:09 AM


Also, when you're talking of a layered approach such that other developers should be using your modelling engine, then you'll have to learn the 3D engine you choose extremely well to inspire confidence in them, and to be able to solve problems that may occur in any of the layers. If you write the WebGL interfacing yourself, you'll (hopefully) become familiar with the potential issues earlier and gain a deeper understanding.

 

Thanks AgentC. This had not crossed my mind!







PARTNERS