On Tue, 08 Jul 2014 09:03:37 -0700, Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote:
https://news.ycombinator.com/newest (please find and vote quickly) https://twitter.com/D_Programming/status/486540487080554496 https://www.facebook.com/dlang.org/posts/881134858566863 http://www.reddit.com/r/programming/comments/2a5ia9/dconf_2014_day_2_talk_3_designing_an_aurora_a/ Andrei
So instead of replying to each messages and accumulating a LOT of quoted text I will attempt to answer some of your questions here.
The first is that I would like to challenge the assumption that Scene Graphs are somehow "Less Performant". In fact the they are a very highly performant solution to many problems, yes there are a few drawbacks but they are far outweighed by the performance gains. Remember that when you are designing a system you must consider the system as a whole, it's WAY to easy to get caught up in individual concerns. Most AAA game engines use some form of scene graph. The one I am familiar with is CryENGINE 3. Now those scene graphs are more specialized, but there is absolutely no reason that a scene graph has to be "slow". In fact D's immutability may give the compiler (and us) the ability to build the most performant scene graph in the world.
Scene graphs make relative transforms easy for example, and since that is really all you're doing in 3D, making that easy for the computer is a massive win.
As for similarity in graphics subsystem API's they are, at best, superficial. When you actually try to implement something on top of them, you end up forcing the abstraction far higher than you'd think. Plus the high-level API design was something that Walter, Andrei, and I all agreed on at the start.
I want to reiterate that Aurora is NOT a high-performance game engine and we won't even pretend to try.
The focus on 2D is not about how difficult 2D versus 3D is, but about project scope. We want to build Aurora in components that are useful on their own. Based on previous message traffic in the forum I think that more people will find use for the 2D components than the 3D components.
Writing a DSL for shaders is one of those things that sounds good until you actually try it. There is a LOT of complexity, both at the language level and the number of output variations, within shaders that would have to addressed.
While D is appealing to game designers, Aurora is very explicitly NOT targeting them. They will either create their own engines or using a COTS system that's already available. Walter made this point extremely clear to me when he asked me to take this project on.
Yes, performance is not a goal, because we are intentionally not targeting scenarios where that is the first concern. I understand that a lot of people want Aurora to be a high-performance graphics API with a focus on games, but that isn't our goal. Simplicity is the goal and we will sacrifice performance where it directly conflicts with that goal. If you need a high-performance game engine, I would strongly recommend either creating a custom solution or using an off-the-self system.
-- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
