MarsHut Page 1/13

sandpaperleadSoftware and s/w Development

Oct 31, 2013 (4 years and 7 months ago)


Poll: what 3D APIs do people want?
Asked by
on 2013-06-12T11:10:36-04:00
Hey guys!

I feel like a lot of us are interested in building apps on top of 3D APIs.
Up until now, though, the discussion about what form they might take has
been a bit limited.

We have a lot of great Haxe projects that already use 3D to various
degrees, so I think it's time for a poll. If you have time, please fill out
this form:

*Haxe, 3D and You

I'll share the results as they come in. :-)
Jun 12, 2013
Week 24, 2013
June, 2013
Year 2013
All Answers
Answer by
on 2013-06-12T11:11:52-04:00
Er, quick note: this poll is for anyone who wants to take it, not just for
people with 3D experience.
Answer by
Nicolas Cannasse
on 2013-06-12T11:36:34-04:00
Le 12/06/2013 17:10, Rezmason a écrit :

Completed and twitted, looking forward for the results ;)

Answer by
on 2013-06-12T16:18:28-04:00
Another note: someone pointed out that I had a nutty question. I've dropped
"I don't care about 3D" from the checkbox about 2D graphics running on
Answer by
on 2013-06-14T01:13:50-04:00
Okay, there's a hundred and seven responses so far, so I'm going to start
sifting through the data and misinterpreting it. :-D

The poll was basically a general list of things people might want from a 3D
API, along with approximate quantities of experience people have with Haxe
and with 3D stuff. Naturally, I plan on making a 3D visualization of this
Page 1/13
Poll: what 3D APIs do people want?
stuff, but that will have to wait until the weekend.

*Here's the summary.*
there you can click through to the raw data. I didn't collect names, so
it's all anonymous. (But Cannasse is on row seven.)

I wrote a program to analyze this stuff. Its output is here
Let me explain what it's composed of. Below is the report for the people
who want 2D graphics with hardware acceleration.

"I want my 2D stuff running on graphics hardware."

headcount:61 opinionated:3.40983606557377 urgency:1.67213114754098

[ ]
[1 1 1 ]
[ 2 2 2 1 ]
[3 1 1 ]
[2 2 4 2 3 ]
[2 2 2 3 2 ]
[5 5 2 8 2 ]

"headcount" is the number of responses that checked the statement.
"opinionated" is the average total number of statements that these people
checked. "urgency" is a misnomer â sorry â and is a crude measurement of
how soon the responder might benefit from an implementation of the stated
feature (for "urgency", smaller is sooner).

The 2D matrix below all that is a scatter plot. The X axis is responders'
Haxe experience, and the Y axis is responders' 3D graphics experience.
Again, it's crude, and there are no labels. However, there is enough data
to make inferences. For instance, a third of the people represented in this
graph have half a year of 3D graphics experience or less. Not surprising,
considering the statement. Keep up the good work, 2D people! Furthermore,
their "urgency" implies that they plan to use the API they want within half
a year.

And here's where I point out one of the benefits of having this
conversation: this community has produced many solutions to common
problems, including this one. I encourage anyone who has made any sort of
library that matches the statements included in the poll to raise our
awareness of your work. In this particular case, there are sixty-one people
who might be interested in your hardware-accelerated 2D library.

I'll post more insights after this post. Let me wrap up the explanation.

At the very bottom of the report there's a weird pile of numbers. This is a
venn diagram that I didn't bother to draw. :-) I'm personally interested in
where our community stands on low-level 3D APIs. As the results came in, I
found that people seem to prefer WebGL/OpenGL ES over Stage3D, but also
Page 2/13
Poll: what 3D APIs do people want?
seem to have faith in the community to produce low-level APIs that don't
necessarily resemble either of these existing ones. I wondered whether we
are polarized on this issue or not: after all, these technologies have
caused a lot of disruption and techno-partisanship among their users.

Here's what I found:

Remember, this is specifically a graph of people who want a low-level API
for Haxe's targets. The majority of people who want Stage3D on non-Flash
platforms are also interested in other APIs to target Flash, mostly
WebGL/OGL ES. The majority of people who want WebGL/OGL ES on Flash are
similarly interested in other APIs for HTML5 and native targets.

But most of these people only want one API for themselves, and it's not
Stage3D. Something like WebGL would probably be acceptable to this crowd,
but a big chunk of us think that we as a community could come up with
something even better.

Anyway! I'm not a statistician, and I could be messing up here, so feel
free to sift through the data yourselves. I'll post other insights soon.
Answer by
on 2013-06-14T02:18:14-04:00
Here's some unsurprising findingsâ we want a high-level 3D API, and as I
said before, we want an API that hands our 2D stuff to the GPU.

I think a lot of us see NC's H3D and H2D libraries as candidates for these
roles (though certainly not the only ones). I also think projects like
these need a way to leap over to non-Flash targets without *#if js*
$.tooMuchOf *#else if flash* tooMuch.of *#else* VagueQuantity.TOO_MUCH_OF *
#end* (this) happening. We need a performant low-level API that engine
developers can build on top of. And the responders to the poll agreeâ just
not on what that API should look like. A lot of the comments mention the
need for *some* API that allows for cross-platform 3D.

At least we know where to stick it once it exists. A majority of
respondents want this stuff baked into, sitting on or otherwise associated
with OpenFL, and the "urgency" for a common API in OpenFL is pretty high.
(I'll give this a shot, with a little help from my friends, seeing how many
people stand to benefit. No promises though!)
Answer by
Nicolas Cannasse
on 2013-06-14T05:00:04-04:00
Le 14/06/2013 08:18, Rezmason a écrit :

First thank you for the poll, that's useful feedback for everyone
involved in Haxe+3D.

The results somehow confirms my own view of what we need:

Page 3/13
Poll: what 3D APIs do people want?
- at native level, we have access to GLES, WebGL and Stage3D

- at low level, we need an API that abstract a bit the things: shaders
(using HxSL for instance), buffers and textures (that's what h3d.Engine
and MemoryManager does atm).

- then we need higher level APIs that can be build on this.

In h3d there are several:
- the h2d API that does 2D sprites, tiles, etc.
- the h3d.scene that manages a 3D scene with FBX models, animations, etc
- the new h2d.comp that adds GPU accelerated UI with HTML/CSS-like to
h2d ( for a demo, for the source)

All of them are actually optional, since they rely on h3d low level
core, and not the other way.

As for my plans:

- I'm still not happy with the way HxSL works, it is not stable enough
and very hard to debug, it is good at error checking but too static.
Shaders for instance cannot be extended with additional behaviors,
making it hard to architecture. I'm planning to do (again) a full HxSL
rewrite using a standard Haxe class that generates a shader has it
executes (in a similar way Minko shaders is working, but with macros
help). This will enable overriding specific shader behavior such as mesh
transform, UV calculus or lighting without having to copy paste the
whole shader. Should be easier also to add GLSL output, which is more
and more necessary as we go.

- This should trigger some changes in the way h3d works, but not huge
ones as things are quite isolated. The next important thing would be to
add WebGL/GLES support for h3d.Engine, but this is not a lot of work
once we have the shaders issue solved.

- as for the high level APIs, h2d should remain pretty stable/unchanged

- as for h3d.scene I'm thinking about ways to handle multipass/deferred.
On our current game I have ShadowMapping, Bloom, Gamma, and DepthOfField
working but it requires gamelogic-specific of doing while I would like
to have it handled directly in h3d.scene. Not sure about the way it can
be done in the API though, any advice/example is welcome.

I'm lacking the time to manage h3d as a HaxeFoundation collaborative
project atm and with all these changes I'm happy not to have a lot of
users that will complain about porting their code :) But I would
eventually like h3d to become the standard for 3D in Haxe or the one on
which other highlevel API are built.

Page 4/13
Poll: what 3D APIs do people want?
Any people involved in Haxe and 3D engines are more than welcome to
contact me directly to discuss potential ways to collaborate.

Answer by
Tero Tolonen
on 2013-06-14T08:17:18-04:00
Backend in 1990's I used to work with 3D graphics and would like to update my knowledge by
working with some 3D
code so, might be interested if suitable modules are found.

Mostly I'm interested in shapes, structures and vector mathematics, how to set up scenes, lightning
and so on.
Higher level stuff. I have never been so interested in pixel shaders, environment maps and things
like that,
but if I have time and want some help in algorithms etc of those areas, gmail is teroktolonen

Don't know how much time I have, but at some point could contribute, create demos, docs or code,
tests or similar
Answer by
on 2013-06-14T11:09:21-04:00
Looks like the number of responses went up by thirty-five people or so last
night. These later respondents seem to like WebGL slightly more, and pretty
much all of them want hardware accelerated 2D, so those wanted features
have gotten more popular.

I'm worried about how much my analysis is now affecting the poll, so I'm
going to hush up until the weekend. But that doesn't mean anyone else has
to. :-)
Answer by
Tom Rhodes
on 2013-06-14T11:12:06-04:00
my 2 euro cents. if haxe had an api like away3d that "just worked" across
JS, flash and hxcpp etc. then it would be an insanely great thing.
Answer by
on 2013-06-14T11:29:32-04:00
Away3D is mentioned in the comments a few times, actually. I think a lot of
people who are interested in a WebGL-shaped API are hoping that it will be
easier to port existing WebGL libraries.
Answer by
Tero Tolonen
on 2013-06-14T11:34:04-04:00
Or Three.js - I think the popularity of Three.js is boosting when the WebGL
is rising and if the API to base the Haxe would be similar to that
then porting different extensions from it would not be so difficultçª=q

There seems to be at least this kind of work going on:

Page 5/13
Poll: what 3D APIs do people want?
While the Haxe's point is not to be a JavaScript -wrapper, the amout of
libraries people are writing currently for JS should be taken into
account I believe. In ideal world you could be able to write code in Haxe
and switch the core engine to Three.js in JS target and all
stays the same + you can utilize plugins written there too.

Three.js has a lot of things that are quite well thought over, so it might
serve as a MIT licenced starting point for the Haxe code too.
If I was starting a 3D renderer project perhaps I might start by porting
the Three.js beause it forms a good definition for the SW
project and is thus quite quick to implement as collaborative task.
Answer by
Laurent Bedubourg
on 2013-06-15T08:52:32-04:00
I like three.js but I think openframeworks API is even simpler to work with.

On 14 June 2013 17:34, Tero Tolonen teroktolonen [ at ]






Answer by
on 2013-06-15T09:53:32-04:00
I did not do the poll I have used haxe and worked on 3d flash over a
period but feel I am far from expert on either they both seem to
change fairly rapidly and I am never fully upto date, especially with
3d, which I am probably completely out of date.

I think that the tools away3D have like Prefab really help the
workflow with commercial 3D projects, I never learnt to use Prefab,
but for the designer I worked with it really was a huge benefit, low
level a lot of Haxe developers are interested in the speed and detail
and how the engine works, but 3D work seems to always be 3 times more
work and hassle and stress than 2D, I used to get really excited about
3D, but now if anything I am just as likely to avoid such projects as
they are harder to get right - clients always expect more than is easy
to do with the tech, eg trying to do flash11 3d quality with loads of
polys in flash9, so the tooling side is very important. From my
distance memory of using away3d it was fairly easy to load in a model
with BSP all setup, and I created a dolly class that automated walking
round the camera inside the model. Really powerful stuff but needed if
you want to do really good stuff.
Page 6/13
Poll: what 3D APIs do people want?

For commercial 3D the tool chain is very important, from 3D Max / Maya
to viewers to custom formats that are lighter like awd etc... Really
creating the 3D engine is actually only half the task if haxe makes
stuff that works with Prefab or similar then that would be good, but
3D tooling around viewing and manipulating the the 3D models for the
platform, baking the lighting, bumpmapping and all the tricks, 3D
packages can do some of this but rarely were they designed for the
lower polys that you often have to use. tooling is as just as
important as just the engine.

Really it would be good if haxe in it's exploration in 3D reached out
to communities like the Away3D one to learn and share knowledge.
Otherwise while haxe may make some amazing engines it will end up
relearning other aspects of real users trying to establish workflows
for modelling and animating 3d. But like I said I don't know very
much about it I just know that getting a good end to end workflow and
setups can make all the difference to real commercial projects
succeeding also it's very important as a community to have a clear
idea of the limitations of the techs involved,, so stats on sensible
model sizes, poly counts etc... it really helps with dealing with
clients that want disney style 3D but expect it from Javascript!

Anyway just some thoughts. Looking forward to seeing the results.
Answer by
Tero Tolonen
on 2013-06-15T10:37:38-04:00
I find this project very interesting...a bit like Unity3D in Haxe ?

Just one proof more about that when the language is good enough, good
projects will just appear.

I'm betting Haxe becoming quite popular in coming years. It only takes one
article in .Net or something.
Answer by
on 2013-06-16T11:20:23-04:00
What platforms will your IDE run on? I'd love to see a dedicated Haxe IDE
for Mac.
Answer by
on 2013-06-16T11:50:31-04:00
Updated results, people:



WebGL is more popular than Stage3D, and slightly more popular than a custom
low-level API. Confusingly, the number of people who personally want just
one API is far more than the number of people who want more than one, yet
the majority of people who want Stage3D want another API, and the majority
Page 7/13
Poll: what 3D APIs do people want?
of people who want WebGL want another API!

Does anyone know a statistician? I'm going to go take an Advil.
Answer by
Michael Bickel
on 2013-06-16T15:55:09-04:00
Thanks for sharing the results of the poll. Quite interesting stuff.

I'm messing with 3D in Haxe for a little more than 3 years now and I
always found it a bit sad that there wasnt a well-thought-out
crossplatform solution for it. After reviewing a lot of the available
frameworks together with my experience with other 3D engines(Unreal,
Ogre3D, Horde3D, Panda3D, G3D, Away3D, Sandy3D,... to name a few) over
the years I actually started to write a new 3D engine in Haxe last year.
Im not reinventing the wheel here, it's all based on previous iterations
of stuff I did.

- at low level, we need an API that abstract a bit the things: shaders

Totally resembles my opinion/experience. I want to write a crossplatform
3D-engine in haxe. Thats exactly why I wrote**foo3d/
year. It abstracts the basic
building blocks to deal with the lowlevel grunt-work in its own library.

It's all about a clean architecture at this point. For me, when looking
at the source of a 3D engine, there should be several subsystems located

- a unified, pooled and bulletproof math-lib(Vec2, Vec3, Mat44, Quat, ...)
- an extendable resource-system(manager + implementations + grouping)
with proper state-managment.
- an extendable scene-system + format + tools. This is how scenes are built.
- a spatial-system. You register nodes(from your scene or not) and you
can query them through optimized structures(what is on screen, ...).
- a render-system. Configuration, passes, renderjobs, matrices, meshes,
materials, shaders, sorting, ...

Most important: each system has little to none dependecies on the other
when you strip away specific implementations. E.g. I wanna be able to
use the scene-system without the renderer, etc.

Here is where it gets a bit tricky and hopefully I wont offend
anyone(especially you, Nicolas) with my strong opinion:

I find h3d's library design pretty messed up. Stuff is all over the place.

From my understanding it kinda grew out of the old
to what it is
today. I considered that a good proof concept/prototype back in the day.
Page 8/13
Poll: what 3D APIs do people want?
But I wouldnt have considered using it for something serious. Same still
stands for me with the latest h3d. You got all my respect for using it
to build Evoland. Since you wrote it, you know it inside out so it was
obviously not a big of a deal for you. If I was in your shoes I probably
would start over with a clear vision and refactor/salvage everything
given the necessary time.

Totally resembles my experience. It is a nice alternative for basic
AGAL-shaders on the flash-target. But to be honest, on the other targets
where it boils down to GLSL i'd rather use GLSL directly. If there are
problems I can look up the spec and I know it's bulletproof and used
everywhere. HxSL exploded more than once in my face and it was kinda
hard to remap the logic and math in a way how stuff worked(e.g. skeletal
animation based on dual quaternions). That being said, I decided early
on to allow platform specific shaders to be used with foo3D. That way it
works with GLSL on the gl-based targets and with AGAL on flash. That way
it's still possible to use something like hxsl or glsl2agal as pre-step
to emit shaders for the platform specific implementation.

As outlined above, I'd seperate the scene-representation from rendering
entirely and use an intermediate layer for spatial queries. That way you
can easily reorganize the scenedata to make optimal queries for your
game while the scene-data/-format itself stays untouched. In my book,
all a renderer should ever care about are renderjobs. Those consist of a
matrix, a mesh and a material. When submitting objects to the
renderer(based on spatial queries) they translate to renderjobs which
are then registered with global renderpasses(diffuse, light,...) and
sorted accordingly into renderqueues. In the end the renderer just runs
over the queues and forwards stuff to the lower-level api. In my case
foo3D or my fp10 backend(doing a 2d flashgame, atm).

To everyone with a bit more insight, this might sound familiar. Yeah,
this is basically the outline of a simple submission-based renderer. :)

I'm lacking the time to manage h3d as a HaxeFoundation collaborative

Time is a critical issue for me, too. My dayjob leaves me with little to
none time to work on this stuff. So the progress is steady but slow. But
I have about 80% of the systems working in my hobbyproject. Once I
complete it this summer, the plan is to apply what I learnt about the
design with the fp10-version of the renderer to the foo3D-based 3D one.

As for a collaboration, time is the issue, although I'm more than happy
to throw myself into the ring. Maybe I can find a way to contribute in
some form.

So, now that I put my opinion out there, it's time for you to rip me
apart. Do what the internet does best. Looking forward to feedback :)

- michael aka dazKind
Page 9/13
Poll: what 3D APIs do people want?
Answer by
CaueÌ Waneck
on 2013-06-17T02:30:45-04:00
My 2 cents:

I've done some 3d programming in the past - first with Away3DLite (which I
ported to Haxe at the time), and afterwards with Unity 3D. My first
motivation to start on a C# target was to be able to use Haxe with Unity.
I'm doing a 2D game now, so I'm not that into 3D at the moment. But Unity
is a great engine, and in the future, if we decide to do a 3D game, I'd
choose Unity and Haxe/C#, without a doubt.

With a couple of macros to take care of generating the Inspector code to
deal with Haxe types (e.g. haxe arrays), coding for Unity3D with Haxe
should work as well as pure C# code. Actually macros can be a very powerful
complement to Unity, specially to be able to generate complex inspector
UI's without any awkward OnGUI() handling.

If anyone wants to try it out, I'll be happy to help on the Haxe/C# part if
anything goes wrong.

Answer by
Nicolas Cannasse
on 2013-06-17T03:52:59-04:00

Thanks for contributing to the discussion.

Using pooling here can be a bit subject to discussion, since it requires
manual memory management.


Don't worry I'm perfectly fine with constructive criticism.

I think that the last part is the most important. "given the necessary
time", is what we all would like to have :) My way of doing things is
instead to build things bottom up, and I usually don't hesitate to
refactor things when it's needed, but only when it's time to.

h3d as surely many ways it can be improved, but I still consider it a
good base on which people can contribute to make it better.

Using GLSL as two important drawbacks IMHO:
- you're losing your ability for cross platform, since you can't
generate a different version of your shader if you're running on DirectX
or Stage3D, or whatever that is slighly different from the GLSL version
you've been writing for
- more important to me, you're losing your compile time integration, so
Page 10/13
Poll: what 3D APIs do people want?
you have to write yourself the glue between your shader and your engine,
instead of generating it, which is a waste of time when you want to try
out different new ideas

Right, I agree with that.

ATM h3d is more like a forward renderer thing that does not do any
spacial queries nor sort things out. One of the reasons is that it was
built at first for Galaxy55 which had everything taken care in the game
logic, and then Evoland used a lot of 2D where things needs to be
rendered in the scene order due to the lack of Z infos.

As we work on more complex games at Shiro - currently doing deferred
shading, I'm sure it will evolve in the way you're suggesting.

I'm still curious however how you would the end-user could some kind of
control over it to prevent things happening out-of-order of what it's

One of the good way to collaborate would be for you to suggest actual
API changes (in terms of code) but without any implementation, this will
make it more easy to discuss architecture first.

Answer by
Alexander Kuzmenko
on 2013-06-17T05:46:31-04:00
Take a look:

понеделÑник, 17 иÑнÑ 2013 г., 10:30:45 UTC+4
полÑзоваÑелÑ Cauê Waneck
Answer by
CaueÌ Waneck
on 2013-06-17T14:27:02-04:00
2013/6/17 Alexander Kuzmenko alex [ at ]

That's great!!

I'll have a go contributing with the inspector macros when I have some time
Have you used it in any project? I'd be interested to know your opinions
about using Haxe with Unity.

Answer by
Alexander Kuzmenko
on 2013-06-17T16:00:24-04:00
I don't have any expirience with unity at all. But i know Axgord made some
projects with hx-unity. Try to contact him.

Page 11/13
Poll: what 3D APIs do people want?
понеделÑник, 17 иÑнÑ 2013 г., 22:27:02 UTC+4
полÑзоваÑелÑ Cauê Waneck
Answer by
Chunbiao Huang
on 2013-06-17T21:54:50-04:00
What can I participate in the Project?

2013/6/15 ÐеÑÑÑ ÐеÑÑов petersvp [ at ]
Answer by
Harley Laue
on 2013-06-20T10:51:37-04:00
First off, I'm going to say I think it sounds like a great project and
can't wait to see what's put out :) The rest is inline.

Perhaps not Crysis 2 (first game using CryEngine 3: 2011), but can
handle a slightly older engine pretty well, like the Unreal Engine 3
(first game using it: 2006) ( There's
also things like O3D ( So,
while WebGL is basically just OpenGL ES 2.0, it ends up being fairly
capable (just not as capable as say, OpenGL 4.3 or Direct3D 11.1) but
I'd also be willing to wager, as long as you're not going in expecting
CryEngine 3, it's capable enough for most people (for the time being...
I do think the time is getting close for it to receive an update;
though, it'll likely just be a rebase on ES 3.0.)

Then why make the immediate switch to Qt 5? I would have thought just
keep forward compatibility in mind, but target 4.8 until 5.x becomes a
viable option.
Answer by
on 2013-06-20T11:01:19-04:00
We switched to Qt5 because of the performance gain, which helped us a lot.
Qt 5.1 beta is way more stable and we will end up in it, but not just the
Qt was our release date stun. We have to do so much stuff, especially with
branding issues... Jobs, and the overal politicial crisis here, in
Bulgaria. Also, we decided that we should implement some more features for
the first release. Anyway, we don't have release date anymore, just keep
checking the blog for details and TO-DO List updates.

2013/6/20 Harley Laue losinggeneration [ at ]
Answer by
on 2013-06-25T00:02:05-04:00
Thanks for the reply, Rob. It's good to have someone so much "in the thick
of 3-D things" to chime in. I would love to see Away3D get serious about
Haxe support because I was a big Papervision3D fan (Away3D's ancestor) and
I liked the API.
Answer by
Harley Laue
on 2013-06-26T14:22:50-04:00
For the question: "How much experience do you have with programming 3D
stuff?" one person answered, "You know what, I've written books on it."
Page 12/13
Poll: what 3D APIs do people want?

To that person, care to share what book(s)? You didn't leave any
comments or projects, so it's just an "out of curiosity question."
3d Apis
Bit Limited
Building Apps
Great Haxe Projects
Hey Guys
Increased focus on H2D/H3D after may 29th ?
hxE - Entity System for Haxe!
Haxe RC2
Database Pooled Connection
Next generation haxelib proposal
implicit type classes with scuts and some macro magic
Sublime Plugin Refactoring : Feedback required
Issues loading redirected images using Loader - CPP
Creating map using templated type T as key type
Haxe plugin for IntelliJ community edition?
View Online
Page 13/13