Graphics Library for D

Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com> Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Tue Jan 7 15:39:31 PST 2014


On Tuesday, 7 January 2014 at 23:08:42 UTC, Ross Hays wrote:
> I also kind of think that having an immediate mode high level 
> API is a bit pointless. It would allow some nice abstractions, 
> but I would still favor retained mode and maybe some quick 
> helper functions that could partially imitate immediate mode 
> (though that should really be a lower priority).

I've looked a bit at the Open Inventor spin-offs: vrml, x3d, 
Coin3d. The latter is actually a BSD clause updated Open Inventor 
2.1 implementation, but it is big and not really useful since it 
is C++. Except as a source for ideas, perhaps. I really wish I 
knew more about SGI's Performer, which was a performance oriented 
scene graph toolkit which could run in parallell.

One possible solution that makes a trade off between ease-of-use 
and performance:

If one accepts an extra latency of 1 frame, then a "buffered" 
mode with intelligent caching might be possible, as a programmer 
friendly effort. That is:

Frame 0:
Thread A: collect draw calls and update accelerator structures, 
cache where possible
Thread B: sleeping

Frame 1:
Thread A: collect draw calls and update accelerator structures, 
cache where possible
Thread B: flush optimized and reordered draw calls to GPU 
(collected in frame 0)

> That is pretty much what I was thinking as well when I was 
> talking about avoiding breaking things into some std.aurora 
> package. Things that phobos could already stand to have such as 
> vectors, audio, better netcode, and so on, may as well be 
> integrated in phobos and then used in Aurora, rather than 
> Aurora becoming some weird extension of phobos.

Yes, I think there are many useful building blocks that can be 
useful in batch mode (for conversion tools) and for game-servers 
that can later be useful for building a render engine.

- Spatial acceleration structures
- ray intersection tests
- object-object intersection tests
- various geometric algorithms (Graphic Gems series)
- mesh algorithms

A lot of this stuff could play nicely together with the 
collection apis, I think.

What would be nice to have in phobos is a idiomatic COLLADA DOM 
and helper functions, because it is a quite intricate file 
format. Maybe that could be a starting point for an engine.




More information about the Digitalmars-d mailing list