DConf 2014 Day 2 Talk 3: Designing an Aurora: A Glimpse at the Graphical Future of D by Adam Wilson

[Adam Wilson via Digitalmars-d-announce]

On Tue, 08 Jul 2014 09:03:37 -0700, Andrei Alexandrescu
<SeeWebsiteForEmail at 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