Hello Fellow D Heads,

Recently, I've been working to evaluate the feasibility and reasonability of building out a binding to Cinder in D. And while it is certainly feasible to wrap Cinder, that a binding would be necessarily complex and feel very unnatural in D.

So after talking it over with Walter and Andrei, we feel that, while we like how Cinder is designed and would very much like to have something like it available in D, wrapping Cinder is not the best approach in the long-term.

With that in mind, we would like to start a discussion with interested parties about building a graphics library in the same concept as Cinder, but using an idiomatic D implementation from the ground up. Walter has suggested that we call it Aurora, and given the visual connotations associated with that name, I think it is most appropriate for this project.

I know that the community has worked through a few of the problems involved. For example, I can't remember who wrote it, but I've seen a module floating around that can create a window in a cross-platform manner, and I know Mike Parker has been heavily involved in graphics for D. And no discussion of graphics would be complete without Manu, whose input Walter, Andrei, and I would greatly appreciate.

I want to point out that while Cinder will be the design template, the goal here is to use D to it's maximum potential. I fully expect that what we end up with will be quite different than Cinder.

Due to the scope of the project I think it would be best to execute the project in stages. This will allow us to deliver useful chunks of working code to the community. Although I haven't yet heard anything on the subject, I would assume that once Aurora reaches an acceptable quality bar it would be a candidate for inclusion in Phobos, as such I would like to approach the design as if that were the end goal.

The logical phases as I can see them are as follows, but please suggest changes:

- Windowing and System Interaction (Including Keyboard/Mouse/Touch Input)
- Basic Drawing (2D Shapes, Lines, Gradients, etc)
- Image Rendering (Image Loading, Rendering, Modification, Saving, etc.)
- 3D Drawing (By far the most complex stage, so we'll leave it for last)

Here are a couple of things that Aurora is not intended to be:
- Aurora is not a high-performance game engine. The focus is on making a general purpose API  that is accessible to non-graphics programmers. That said, we don't want to purposely ruin performance and any work and guidance on that aspect will be warmly welcomed.
- Aurora is not a GUI library. Aurora is intended as a creative graphics programming library in the same concept as Cinder. This means that it will be much closer to game's graphics engine, in terms of design and capability, than a UI library; therefore we should approach the design from that standpoint.

My personal experience in graphics programming is almost completely with DirectX and Windows so I would be happy to work on support for that platform. However, we need to support many other platforms, and I know that there are others in the community have the skills needed, your help would be invaluable.

If you are interested in helping with a Cinder like library for D and/or have code you'd like to contribute, let's start talking and see what happens.

While I do have some ideas about how to design the library, I would rather open the floor to the community first to see what our combined intellect has to offer as I don't want to unduly influence the ideas generated here. The idea is to build the best technical graphics library that we can, not measure egos.

So with the above framework in mind, let's talk!

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On 1/5/2014 8:10 PM, Adam Wilson wrote:
> Recently, I've been working to evaluate the feasibility and reasonability of
> building out a binding to Cinder in D.

For reference, here's what Cinder is:

http://libcinder.org/

It's been well received by the C++ community.

On Monday, 6 January 2014 at 04:11:07 UTC, Adam Wilson wrote:
> Hello Fellow D Heads,
>
> Recently, I've been working to evaluate the feasibility and reasonability of building out a binding to Cinder in D. And while it is certainly feasible to wrap Cinder, that a binding would be necessarily complex and feel very unnatural in D.
>
> So after talking it over with Walter and Andrei, we feel that, while we like how Cinder is designed and would very much like to have something like it available in D, wrapping Cinder is not the best approach in the long-term.
>
> With that in mind, we would like to start a discussion with interested parties about building a graphics library in the same concept as Cinder, but using an idiomatic D implementation from the ground up.

I assume that the licence will be BOOST ??

A picture is worth a thousand words, therefore is this the type of graphics library output you are refering to:

http://marcinignac.com/projects/cindermedusae/

Nick

I'm sure you'll receive no shortage of opinions with such an open invitation, so here's mine:

* Please don't make a graphics library that is useful only on PCs.

* Please consider more than mouse and keypboard as input devices (e.g. multitouch)

* Today is the first I've heard of Cinder, but if you really want to see an extremely well-written graphics library, take a look at AGG (Anti-Grain Geometry).  It's is a superior example of elegantly employed templates for a real practical problem (lot of different platforms). As an example illustrating its reach, I ported it to an ARM Cortex-M4 MCU at 168MHz with 2MB of RAM trivial modification.  It powers an 800x480 7" TFT LCD with 16-bit color and is damn fast.  For a quick intro, go here (http://www.antigrain.com/doc/introduction/introduction.agdoc.html#toc0006).  It is superior design model for anyone wishing to develop a graphics library.

* Break the library into loosely coupled pieces that can be used individually or aggregated by other projects to build things that we haven't even thought of
  *  Geometric primitives should be their own library/package
  *  Vector graphics (paths, line caps, etc...) should be their own library/package
  *  Raster graphics should be their own library/package
  *  Window management should be its own library/package
  *  Font's are just data.  Don't couple them to the rendering engine.  (e.g  Convert them to a vector/raster representation and then let those libraries handle the rest.
  *  The rendering engine should be its own library/package, that should be easily replaced with whatever is suitable for the given platform.

I think Aurora should be a library of libraries that can be used individually or aggregated to build new and exciting projects that you and I haven't yet even thought of.  Think std.algorithm.

> The logical phases as I can see them are as follows, but please suggest changes:

Start with the most primitive and move up from there (If loosely coupled, the could be developed in parallel)
1. Geometric primitives
2. Vector graphics
3. Fonts (just a special case of vector graphics)
4. Rasterization
5. Backend (Direct2D/3D, OpenGL, OpenVG, whatever)

Once that is done, Widget libraries, Windowing, Input Device handling, etc... can all be built on top of that.

A graphics library is something I will need in my future D plans, so I look forward to seeing where this goes, and I hope I'll be able to make a positive contribution or two myself.

But, please play a little with AGG before you begin your design.  I think you'll be glad you did. (http://www.antigrain.com/)

On Sun, 05 Jan 2014 20:58:11 -0800, Nick B <nick.barbalich@gmail.com> wrote:

> On Monday, 6 January 2014 at 04:11:07 UTC, Adam Wilson wrote:
>> Hello Fellow D Heads,
>>
>> Recently, I've been working to evaluate the feasibility and reasonability of building out a binding to Cinder in D. And while it is certainly feasible to wrap Cinder, that a binding would be necessarily complex and feel very unnatural in D.
>>
>> So after talking it over with Walter and Andrei, we feel that, while we like how Cinder is designed and would very much like to have something like it available in D, wrapping Cinder is not the best approach in the long-term.
>>
>> With that in mind, we would like to start a discussion with interested parties about building a graphics library in the same concept as Cinder, but using an idiomatic D implementation from the ground up.
>
> I assume that the licence will be BOOST ??
>
> A picture is worth a thousand words, therefore is this the type of graphics library output you are refering to:
>
> http://marcinignac.com/projects/cindermedusae/
>
> Nick
>

I don't think anyone here has a problem with Boost licensing so I think it would be be safe to assume that license.

That is indeed an example of something that you can do with Cinder, and another would would be Planetary: http://planetary.bloom.io/

The idea is too allow a wide range of graphics capabilities in a format that is accessible to non-graphics programmers while using D. Walter, Andrei, and I believe that D's relative simplicity when compared to C++ makes this kind of project of ideal for D and people who are looking to write graphics code without having to learn the intricacies of C++.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Sun, 05 Jan 2014 21:32:54 -0800, Mike <none@none.com> wrote:

> I'm sure you'll receive no shortage of opinions with such an open invitation, so here's mine:
>
> * Please don't make a graphics library that is useful only on PCs.
>

That's the plan. However at this point D only works on x86 so it's a moot point. But if we built a pluggable rendering backend that would allow us to swap the rendering that should be sufficient.

> * Please consider more than mouse and keypboard as input devices (e.g. multitouch)
>

Definitely. I included touch on my list because even outside the phone/tablet market it can be useful. All my desktops have a touch monitor.

> * Today is the first I've heard of Cinder, but if you really want to see an extremely well-written graphics library, take a look at AGG (Anti-Grain Geometry).  It's is a superior example of elegantly employed templates for a real practical problem (lot of different platforms). As an example illustrating its reach, I ported it to an ARM Cortex-M4 MCU at 168MHz with 2MB of RAM trivial modification.  It powers an 800x480 7" TFT LCD with 16-bit color and is damn fast.  For a quick intro, go here (http://www.antigrain.com/doc/introduction/introduction.agdoc.html#toc0006).   It is superior design model for anyone wishing to develop a graphics library.
>

I've heard of it, and we are definitely open to stealing the best of any library, so I/we take a look at it.

> * Break the library into loosely coupled pieces that can be used individually or aggregated by other projects to build things that we haven't even thought of
>    *  Geometric primitives should be their own library/package
>    *  Vector graphics (paths, line caps, etc...) should be their own library/package
>    *  Raster graphics should be their own library/package
>    *  Window management should be its own library/package
>    *  Font's are just data.  Don't couple them to the rendering engine.  (e.g  Convert them to a vector/raster representation and then let those libraries handle the rest.

This is a good idea, I like it.

>    *  The rendering engine should be its own library/package, that should be easily replaced with whatever is suitable for the given platform.
>

As in pluggable backend? That should be easy enough to do.

> I think Aurora should be a library of libraries that can be used individually or aggregated to build new and exciting projects that you and I haven't yet even thought of.  Think std.algorithm.
>

Combined with the above idea this would be an excellent demonstration of D's capabilities. And it would definitely improve the design of the library.

>> The logical phases as I can see them are as follows, but please suggest changes:
>
> Start with the most primitive and move up from there (If loosely coupled, the could be developed in parallel)
> 1. Geometric primitives
> 2. Vector graphics
> 3. Fonts (just a special case of vector graphics)
> 4. Rasterization
> 5. Backend (Direct2D/3D, OpenGL, OpenVG, whatever)
>

The problem I can see here is that if you want to test the first four, number five has to be built out to some degree.

> Once that is done, Widget libraries, Windowing, Input Device handling, etc... can all be built on top of that.
>
> A graphics library is something I will need in my future D plans, so I look forward to seeing where this goes, and I hope I'll be able to make a positive contribution or two myself.
>

Indeed, a graphics library is required for my future plans as well. Which is why I am speadheading this project. :-)

> But, please play a little with AGG before you begin your design.  I think you'll be glad you did. (http://www.antigrain.com/)
>

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Sun, 05 Jan 2014 20:17:22 -0800, Walter Bright <newshound2@digitalmars.com> wrote:

> On 1/5/2014 8:10 PM, Adam Wilson wrote:
>> Recently, I've been working to evaluate the feasibility and reasonability of
>> building out a binding to Cinder in D.
>
> For reference, here's what Cinder is:
>
> http://libcinder.org/
>
> It's been well received by the C++ community.
>

I knew forgot something!

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Monday, 6 January 2014 at 04:11:07 UTC, Adam Wilson wrote:
> - Aurora is not a GUI library. Aurora is intended as a creative graphics programming library in the same concept as Cinder. This means that it will be much closer to game's graphics engine, in terms of design and capability, than a UI library; therefore we should approach the design from that standpoint.

Sorry, what does it mean? For example, I want to create minimal GUI (1-2 buttons and text fields). Do you have any plans to support it?

On Monday, 6 January 2014 at 04:17:21 UTC, Walter Bright wrote:
> On 1/5/2014 8:10 PM, Adam Wilson wrote:
>> Recently, I've been working to evaluate the feasibility and reasonability of
>> building out a binding to Cinder in D.
>
> For reference, here's what Cinder is:
>
> http://libcinder.org/
>
> It's been well received by the C++ community.

I took a look at the website.  Other than being popular what is it about Cinder that triggered this graphics push: do they make any good technical decisions?  I can't tell just from looking at their website.

On Sun, 05 Jan 2014 23:25:38 -0800, ilya-stromberg <ilya-stromberg-2009@yandex.ru> wrote:

> On Monday, 6 January 2014 at 04:11:07 UTC, Adam Wilson wrote:
>> - Aurora is not a GUI library. Aurora is intended as a creative graphics programming library in the same concept as Cinder. This means that it will be much closer to game's graphics engine, in terms of design and capability, than a UI library; therefore we should approach the design from that standpoint.
>
> Sorry, what does it mean? For example, I want to create minimal GUI (1-2 buttons and text fields). Do you have any plans to support it?

Not at present, you could certainly use it to build a custom minimal GUI toolkit but that is not it's primary function. It would probably be best to think about Aurora as a graphics rendering toolkit. You tell us how to draw the pixels and we'll do it as best we can on that device.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator