On Wed, 08 Jan 2014 15:45:45 -0800, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Wednesday, 8 January 2014 at 23:11:34 UTC, finalpatch wrote:
>> The fork on SourceForge, although considered maintained, it contains only a few small changes. Right now the revision number of that repo is only about 90, and there isn't much happening in the repo over the years. I think if we pick up the
>
> Sadly, the author apparently died in november:
>
> http://www.microsofttranslator.com/bv.aspx?from=ru&to=en&a=http://rsdn.ru/forum/life/5377743.flat

Wow, that is sad! Kind of puts the whole project in an interesting spot...

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Wednesday, 8 January 2014 at 23:56:19 UTC, finalpatch wrote:
> we can produce something even more impressive than AGG. Since it's a pure software renderer, the scope of the project will be a lot more manageable than GPU based solutions.

You could try the REYES algorithm, it should give more accurate results than the scanline AGG uses (which I assume uses alphablending for aliasing which produce inaccurate results where edges meet.).

http://en.wikipedia.org/wiki/Reyes_rendering

Basically you partition edges into sub-pixel polygons and sort them. Then you calculate visibility and coverage before shading.

You can also render stuff like fur with it because of the precision you might be able to get on the subpixel level.

On Thursday, 9 January 2014 at 00:20:00 UTC, Ola Fosheim Grøstad wrote:
> Basically you partition edges into sub-pixel polygons and sort them. Then you calculate visibility and coverage before shading.

(note: this is not how REYES work for 3D, but I think it could be adapted with good results for non-realtime 2D this way.)

On 1/9/2014 3:42 AM, Adam Wilson wrote:

> the standard library. In principle, I don't really have a problem with
> that, however as someone pointed out, you don't really expect to be able
> to use std.socket without a NIC, so saying that it shouldn't be in just
> because not all machines have graphics output is tad extreme.

What I'm saying is that if it *is* in Phobos, then there should be a software renderer so that it *is* available to use on machines with no graphics card. If it isn't in Phobos, then I wouldn't see a software renderer as a requirement.

On 1/8/2014 11:05 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:

>
>> I wouldn't expect any implementation, generic or otherwise, to assume
>> mostly static geometry. You could bet that a simple graphics API in
>> Phobos would be used for games by some and for generating pie charts
>> by others. It's still possible to get a generic rendering system to
>> handle that with decent performance. Yes, it makes for compromises in
>> the backend that a more targeted renderer wouldn't need to make, but
>> that's the price of genericity.
>
> 2D games, web browsers etc use geometry that is mostly static between
> frames (although it can be hidden). So you can cache and have a
> dirty-flag on each surface (if the path-data change you set the dirty
> flag and the engine recreates the cached surface). 3D is different
> because of the perspective effect which force you to a complete redraw
> every frame.
>

Is this going to provide a 3D renderer as well? I thought we were just talking about 2D.

On Thursday, 9 January 2014 at 01:56:59 UTC, Mike Parker wrote:
> Is this going to provide a 3D renderer as well? I thought we were just talking about 2D.

My point was that 2D is better suited for caching and reusing rasters from previous frames than 3D. So it benefit from not being fully immediate mode. Although if you cache by indexing the id of a shape object, it looks like immediate mode.

I have no idea if it is supposed to provide 3D. It was suggested as a future extension I suppose?

On Wed, 08 Jan 2014 17:55:20 -0800, Mike Parker <aldacron@gmail.com> wrote:

> On 1/9/2014 3:42 AM, Adam Wilson wrote:
>
>> the standard library. In principle, I don't really have a problem with
>> that, however as someone pointed out, you don't really expect to be able
>> to use std.socket without a NIC, so saying that it shouldn't be in just
>> because not all machines have graphics output is tad extreme.
>
> What I'm saying is that if it *is* in Phobos, then there should be a software renderer so that it *is* available to use on machines with no graphics card. If it isn't in Phobos, then I wouldn't see a software renderer as a requirement.
>

That's fair, and I don't think anyone here would disagree. Software renderers are hard things to write though, so I don't expect we'll get one early on. But I'd like to include one at some point...

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Wed, 08 Jan 2014 18:17:11 -0800, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Thursday, 9 January 2014 at 01:56:59 UTC, Mike Parker wrote:
>> Is this going to provide a 3D renderer as well? I thought we were just talking about 2D.
>
> My point was that 2D is better suited for caching and reusing rasters from previous frames than 3D. So it benefit from not being fully immediate mode. Although if you cache by indexing the id of a shape object, it looks like immediate mode.
>
> I have no idea if it is supposed to provide 3D. It was suggested as a future extension I suppose?

Yes, it is supposed to provide 2D and 3D and ideally have both in the same window.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On 2014-01-08 19:39, David Gileadi wrote:

> I think if you're willing to use version 2.4 then you get a much more
> permissive license, no? That's how I read
> http://www.antigrain.com/license/index.html anyway...

Looks like it's less permissive than the Boost license due to point 2.

-- 
/Jacob Carlborg

On Thursday, 9 January 2014 at 02:21:41 UTC, Adam Wilson wrote:
> Yes, it is supposed to provide 2D and 3D and ideally have both in the same window.

Then we should decide what the 2D surface properties are:

1. Are they z-ordered or do we use painters-algorithm (drawing back to front), basically: how should 3D and 2D blend into each other?

2. Are they considered to be transparent all over the surface, or are the non-transparent parts of them to be handled more efficiently?

3. Are they to be scaled as bitmaps or are they going to have exact precision.

If it is desirable to skip the compositor complexity I'd say try to go entirely for triangular geometry and shaders in the first version and treat 2D the same way you treat 3D, but have shape objects so that you don't have to constantly transfer meshes to the GPU.

Pre rendering:
1. build shape objects.
2. build graphic contexts with various transforms and setups (colours, scaling).
2. register shape objects with engine with expected min-max LOD level (mesh resolution).
3. engine preloads data to the GPU if desirable.

Per frame:
1. get graphic contexts with various transforms and setups (colours, scaling)
2. toss shape object id's to the engine through a graphic context
3. engine queues transparent parts and renders non-transparent parts immediately
4. engine sorts transparent parts and render them

It will probably not be very fast for 2D, but it is the better starting point if you later want to mix 2D and 3D. Besides, by the time the framework is ready maybe most GPUs have fast enough shaders for this to be the best way to do it for larger shapes (then you can special case for smaller shapes later by drawing to them to textures).