Poll: what 3D APIs do people want?

[Rezmason]

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. :-)

[Rezmason]

Er, quick note: this poll is for anyone who wants to take it, not just for people with 3D experience.

[Nicolas Cannasse]

Le 12/06/2013 17:10, Rezmason a �crit :

> 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:

Completed and twitted, looking forward for the results ;)

Best,
Nicolas

[Rezmason]

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 hardware.

[Rezmason]

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 stuff, but that will have to wait until the weekend.

Here's the summary. From 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 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.

[Rezmason]

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!)

[Nicolas Cannasse]

Le 14/06/2013 08:18, Rezmason a �crit :
> 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!)

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:

- 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 (http://ncannasse.github.io/h3d/samples/comps/index.html for a demo,
http://bit.ly/19ygDcu 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.

Any people involved in Haxe and 3D engines are more than welcome to
contact me directly to discuss potential ways to collaborate.

Best,
Nicolas

[Tero Tolonen]

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

[Rezmason]

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. :-)

[tom rhodes]

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. 

On 14 June 2013 17:09, Rezmason <jeremy...@gmail.com> wrote:

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. :-)

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Rezmason]

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.

[Tero Tolonen]

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

   http://www.google.com/trends/explore?q=Three.js#q=Three.js&cmpt=q

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

   https://github.com/labe-me/haxe-three.js

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.

[Laurent Bedubourg]

I like three.js but I think openframeworks API is even simpler to work with.

--
Laurent Bédubourg
lau...@labe.me
http://labe.me

--
Laurent Bédubourg
lau...@labe.me
http://labe.me

[j...@justinfront.net]

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.

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.

[Петър Петров]

We, at Pi-Dev, are currently implementing Ogre3D frontend for Haxe, but not Ogre mapping for Haxe. Our Engine's framework is a haxe library that uses Ogre for rendering of our own primitive and objects, that is, we use Ogre just for own rendering. 

We are also developing a Haxe IDE around this (Creator IDe is both a level designer tool AND Haxe programming IDE), so, when we release our product we will definetly do some contribution to Haxe. Our Free version will be Free, and we will make our IDE usable as General-purpose Haxe IDE, like FlashDevelop, just with some cool "level editor" tied to our own framework with options to write exporters for this editor to different Haxe libraries, for example, to NME)

---

Pi-Dev: pi | engine - multiplatform game engine

[Tero Tolonen]

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.

[Петър Петров]

In fact our "career" started with Y0y0 G@mes's g@me m@ker [I don't want this indexed by google :D] but we didn't like the way it behaves.

Unity is very good, just not this we expect - it's "marriaged" to Mono... Which I don't like so much and hxcpp always get better performance on my own mashine.

We don't want ourselves to compete Unity seriously, we may even write a "Unity  exporter" someday, as unity's API is a lot better than M$'s XNA... At least from our own perspective.

Haxe is perfect but have a serious flaw: Investors STILL see it as Flash-targetted language... It is so WELL targetted fo Flash from a "word of mouth" point of view, and this is stunning us bad when finding investors... The language is MILLIONS of ways better to be "just flash" related, and We are trying to contribute to change this a bit.

Yes, we are primarily targetting Desktop and Game consoles, because as you all know, WebGL just can't run Crysis 2 :)

We will use either Copperlicht or if h3d comes good enough, h3d, for Web games. Just we have and we need some more time to release the first "proof of concept" version of our project. Qt introduced a lot of bugs into Qt 5.0 and this killed our initial release date...

[Rezmason]

What platforms will your IDE run on? I'd love to see a dedicated Haxe IDE for Mac.

[Rezmason]

Updated results, people:

Summary

Output

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 of people who want WebGL want another API!

Does anyone know a statistician? I'm going to go take an Advil.

[Петър Петров]

The IDE will run on all desktop platforms supported by Qt. This includes Linux and Mac. However, I have no idea when We will be able to properly port the IDE to Linux And Mac, so first betas will be windows-only...

[Michael Bickel]

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
(using HxSL for instance), buffers and textures (that's what h3d.Engine
and MemoryManager does atm).

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

 

- 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 (http://ncannasse.github.io/h3d/samples/comps/index.html for a demo,
http://bit.ly/19ygDcu for the source)

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

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
here:

- 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
haxe3d-implementation(https://code.google.com/p/haxe3d/) to what it is
today. I considered that a good proof concept/prototype back in the day.
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. 

 

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. 

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 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. 

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
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.

Any people involved in Haxe and 3D engines are more than welcome to
contact me directly to discuss potential ways to collaborate.

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
www.developium.net

[Cauê Waneck]

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.

Cheers

Cauê

[Nicolas Cannasse]

Hi,

Thanks for contributing to the discussion.

> 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
> here:
>
> - a unified, pooled and bulletproof math-lib(Vec2, Vec3, Mat44, Quat, ...)

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

[...]

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

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

> 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

> haxe3d-implementation(https://__code.google.com/p/haxe3d/
> <https://code.google.com/p/haxe3d/>) to what it is

> today. I considered that a good proof concept/prototype back in the day.
> 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.

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.

> 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.

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
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

> - 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.
>
>
> 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).

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
expecting.

> 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.

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.

Best,
Nicolas

[Alexander Kuzmenko]

Take a look: https://github.com/AxGord/hx-unity3d

понедельник, 17 июня 2013 г., 10:30:45 UTC+4 пользователь Cauê Waneck написал:

[Cauê Waneck]

2013/6/17 Alexander Kuzmenko <al...@stablex.ru>

Take a look: https://github.com/AxGord/hx-unity3d

That's great!!

I'll have a go contributing with the inspector macros when I have some time available.

Have you used it in any project? I'd be interested to know your opinions about using Haxe with Unity.

Cheers!

Cauê

--

[Alexander Kuzmenko]

I don't have any expirience with unity at all. But i know Axgord made some projects with hx-unity. Try to contact him.

понедельник, 17 июня 2013 г., 22:27:02 UTC+4 пользователь Cauê Waneck написал:

[chunbiao huang]

What can I participate in the Project?

2013/6/15 Петър Петров <pete...@gmail.com>

--

[Harley Laue]

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.

On 06/15/13 09:50, пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ wrote:
> In fact our "career" started with Y0y0 G@mes's g@me m@ker [I don't
> want this indexed by google :D] but we didn't like the way it behaves.
>
> Unity is very good, just not this we expect - it's "marriaged" to
> Mono... Which I don't like so much and hxcpp always get better
> performance on my own mashine.
> We don't want ourselves to compete Unity seriously, we may even write
> a "Unity exporter" someday, as unity's API is a lot better than M$'s
> XNA... At least from our own perspective.
>
> Haxe is perfect but have a serious flaw: Investors STILL see it as
> Flash-targetted language... It is so WELL targetted fo Flash from a
> "word of mouth" point of view, and this is stunning us bad when
> finding investors... The language is MILLIONS of ways better to be
> "just flash" related, and We are trying to contribute to change this a
> bit.
>
> Yes, we are primarily targetting Desktop and Game consoles, because as
> you all know, WebGL just can't run Crysis 2 :)

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) (http://www.unrealengine.com/html5) There's
also things like O3D (https://www.youtube.com/watch?v=uofWfXOzX-g) 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.)

> We will use either Copperlicht or if h3d comes good enough, h3d, for
> Web games. Just we have and we need some more time to release the
> first "proof of concept" version of our project. Qt introduced a lot
> of bugs into Qt 5.0 and this killed our initial release date...

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.

> 15 пїЅпїЅпїЅ 2013, пїЅпїЅпїЅпїЅпїЅпїЅ, 17:37:38 UTC+3, Tero Tolonen пїЅпїЅпїЅпїЅпїЅпїЅ:

>
>
> 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.
>
>
>
>
> On Saturday, June 15, 2013 5:13:48 PM UTC+3, пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ wrote:
>
> We, at Pi-Dev, are currently implementing Ogre3D frontend for
> Haxe, but not Ogre mapping for Haxe. Our Engine's framework is
> a haxe library that uses Ogre for rendering of our own
> primitive and objects, that is, we use Ogre just for own
> rendering.
>
> We are also developing a Haxe IDE around this (Creator IDe is
> both a level designer tool AND Haxe programming IDE), so, when
> we release our product we will definetly do some contribution
> to Haxe. Our Free version will be Free, and we will make our
> IDE usable as General-purpose Haxe IDE, like FlashDevelop,
> just with some cool "level editor" tied to our own framework
> with options to write exporters for this editor to different
> Haxe libraries, for example, to NME)
>

> 12 пїЅпїЅпїЅ 2013, пїЅпїЅпїЅпїЅпїЅ, 18:10:36 UTC+3, Rezmason пїЅпїЅпїЅпїЅпїЅпїЅ:

>
> 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
> <https://docs.google.com/forms/d/12tEzNVVBY8nN8ieg5SCrpfdsiNw_RR4SS8QDcjdSRzw/viewform>_*
> *_
> _*

> I'll share the results as they come in. :-)
>

[PeterSvP]

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 <losingge...@gmail.com>

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.

On 06/15/13 09:50, Петър Петров wrote:

In fact our "career" started with Y0y0 G@mes's g@me m@ker [I don't want this indexed by google :D] but we didn't like the way it behaves.

Unity is very good, just not this we expect - it's "marriaged" to Mono... Which I don't like so much and hxcpp always get better performance on my own mashine.
We don't want ourselves to compete Unity seriously, we may even write a "Unity  exporter" someday, as unity's API is a lot better than M$'s XNA... At least from our own perspective.

Haxe is perfect but have a serious flaw: Investors STILL see it as Flash-targetted language... It is so WELL targetted fo Flash from a "word of mouth" point of view, and this is stunning us bad when finding investors... The language is MILLIONS of ways better to be "just flash" related, and We are trying to contribute to change this a bit.

Yes, we are primarily targetting Desktop and Game consoles, because as you all know, WebGL just can't run Crysis 2 :)

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) (http://www.unrealengine.com/html5) There's also things like O3D (https://www.youtube.com/watch?v=uofWfXOzX-g) 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.)

We will use either Copperlicht or if h3d comes good enough, h3d, for Web games. Just we have and we need some more time to release the first "proof of concept" version of our project. Qt introduced a lot of bugs into Qt 5.0 and this killed our initial release date...

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.

15 юни 2013, събота, 17:37:38 UTC+3, Tero Tolonen написа:


    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.




    On Saturday, June 15, 2013 5:13:48 PM UTC+3, Петър Петров wrote:

        We, at Pi-Dev, are currently implementing Ogre3D frontend for
        Haxe, but not Ogre mapping for Haxe. Our Engine's framework is
        a haxe library that uses Ogre for rendering of our own
        primitive and objects, that is, we use Ogre just for own
        rendering.

        We are also developing a Haxe IDE around this (Creator IDe is
        both a level designer tool AND Haxe programming IDE), so, when
        we release our product we will definetly do some contribution
        to Haxe. Our Free version will be Free, and we will make our
        IDE usable as General-purpose Haxe IDE, like FlashDevelop,
        just with some cool "level editor" tied to our own framework
        with options to write exporters for this editor to different
        Haxe libraries, for example, to NME)

        12 юни 2013, сряда, 18:10:36 UTC+3, Rezmason написа:

            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
            <https://docs.google.com/forms/d/12tEzNVVBY8nN8ieg5SCrpfdsiNw_RR4SS8QDcjdSRzw/viewform>_*
            *_
            _*

            I'll share the results as they come in. :-)

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---

You received this message because you are subscribed to the Google Groups "Haxe" group.

For more options, visit https://groups.google.com/groups/opt_out.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

--- You received this message because you are subscribed to a topic in the Google Groups "Haxe" group.

[Rob Bateman]

Hey Guys

Don't stick my oar into the Haxe group as often as i would like, but I wanted to give the Away3D perspective on the 3D-engine-aspect of Haxe.

I hear a lot of "we want high level" stuff and thats exactly what Away3D provides (on the flash side at least) at the moment. You don't need to be a shader whizz and you don't need a degree in 3Ding, but we of course leave the door open for those that are to hack and extend the api.

I think it would be great for Haxe to have something Away3D-like and I'd like to say that we can spend some time developing a port but the truth is that we can't dedicate the necessary resources to something so removed from our current platform. And while the Away Foundation is an independent organisation, we obviously do need to pay attention a little to where our sponsors are coming from, at least if we still want them to be sponsors in future.

Having said that, we do have something in the pipes that might be of use to the Haxe community, or at the very least the HaxeNME group. One of the biggest steps for a Haxe conversion of Away3D has got to be what we do with shaders. Personally, i don't see any reason not to do GLSL. After all, if you're targeting the Flash Platform with your Haxe project, you can always use an Away3D swc direct. GLSL and AGAL don't really get on when it comes to conversion, but I'm pleased to say we are already making our own headway with that step in a different conversion currently ongoing: the Away3D-TypeScript branch. Theres not much to see at the moment, but we plan to have something released around October time - and i would bet that a Typescript > Haxe conversion would be considerably less painful than an AS3 > Haxe conversion of Away3D, primarily because all the shader work will be already done.

Now I can already here some of you saying "but Rob, if you forgot about Typescript and just converted to Haxe, you'd be able to target both browser AND native desktop AND native mobile". Which is true. But all i can say at this time is that a) sadly, thats not what we're being paid to do at the moment, and b) from a community perspective, a TypeScript / Javascript library has a lot more legs than a Haxe library and makes perfect sense for a company dedicated to producing free tools for communities to use.

Of course, all this could change if someone was willing to help us out with the necessary support (Blackberry, i'm looking at you!), and failing that, we are of course completely open to geting help from inside the Haxe community for a conversion - and would be only too happy to get the ball rolling if there are willing participants. So if anyone is up for the task then PM me or whatever you do in google groups these days and lets work something out. ;) 

Rob

Rob Bateman
Flash Development & Consultancy

rob.b...@gmail.com
www.infiniteturtles.co.uk
www.away3d.com

[Confidant]

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.

[Harley Laue]

On 06/12/13 10:10, Rezmason wrote:

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. :-)

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."

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."