3D Engine incubator - next step.

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

3D Engine incubator - next step.

sledorze
Hi!

Thanks all for your participation at Yersterday first Hide3D (temporary name) meeting.
Theres was a lot of discussion and exchange,
For those who had not the possibility to join; the log is available here:
http://haxe.org/com/incubator/3dengine/log_6_12_2011

I propose you guys to create entries on the domain you own, just to do basic, short documentation on what have been agreed and/or design choices for internal usage (on haxe wiki).

(Nicolas, if you think this is abusing haxe's wiki, please tell us).

In the end, what we agreed on was to make a first quick milestone; basically a cube and a camera controller (unreal like).
It will help defining the interface with the different targets dans help the teams to work in parallel.

A lot is undefined, and that's fine, I prefer seeing sinergy, progress and being reactive rather that over engineering a spec (we're not building html here ^^) - we'll discover a lot this way.

We'll meet next sunday, I would propose it 2 hours later.
This meeting subject is the kick off of the first milestone, basically, after one week of thought, agreeing on the 'what' but also the 'who', 'when' and 'how' and start a sprint.

As always, feel free to post :)
Stephane
Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

Cauê W.
Sorry I haven't been able to participate. The time was a little bad for me.

Anyway, I haven't read the whole log, but here are some thoughts:

  • I think it's a good idea to have a first sprint not based on away3d, to get the idea of the whole
  • I'd take off any reference to the flash api. This would mean not to use nme in this case. THis is because I think it would be important to have a very clean and fast solution to the 3D part. We could then build on top of that, to implement e.g. vector graphics or text rendering (based on textures, for example). This would be far the most portable solution, so adding another platform target (e.g. a console) would be fairly easy, as the only platform-dependent code would be the 3d (OpenGL, Direct3D) lib iteslf
  • We still have to think of a good and fast way to deal with math objects like Quaternions and Vectors. I'd define it as a struct in C, C++ or C#. Away3D has them setup as reusable objects, which might solve the problem but it bothers me. Maybe a compiler extension could be suggested that would take e.g. a Quaternion object and transform it into x,y,z,w variables? This could be done also with macros, but it would be kind of messy
  • About input formats, I've worked some time ago in a Unity3d->Away3d source code exporter. We could think about doing the same for us. This way we get a editing engine, we can support all cool things that Unity supports (like using PSDs for the testing the textures), and by releasing it to source code we can get a nice strictly-typed scenegraph, and it's as fast as it can get ; )

Cheers!
Caue

2011/6/13 sledorze <[hidden email]>
Hi!

Thanks all for your participation at Yersterday first Hide3D (temporary
name) meeting.
Theres was a lot of discussion and exchange,
For those who had not the possibility to join; the log is available here:
http://haxe.org/com/incubator/3dengine/log_6_12_2011

I propose you guys to create entries on the domain you own, just to do
basic, short documentation on what have been agreed and/or design choices
for internal usage (on haxe wiki).

(Nicolas, if you think this is abusing haxe's wiki, please tell us).

In the end, what we agreed on was to make a first quick milestone; basically
a cube and a camera controller (unreal like).
It will help defining the interface with the different targets dans help the
teams to work in parallel.

A lot is undefined, and that's fine, I prefer seeing sinergy, progress and
being reactive rather that over engineering a spec (we're not building html
here ^^) - we'll discover a lot this way.

We'll meet next sunday, I would propose it 2 hours later.
This meeting subject is the kick off of the first milestone, basically,
after one week of thought, agreeing on the 'what' but also the 'who', 'when'
and 'how' and start a sprint.

As always, feel free to post :)
Stephane


--
View this message in context: http://haxe.1354130.n2.nabble.com/3D-Engine-incubator-next-step-tp6469370p6469370.html
Sent from the Haxe mailing list archive at Nabble.com.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

Nicolas Cannasse
In reply to this post by sledorze
Le 13/06/2011 10:28, sledorze a écrit :

> Hi!
>
> Thanks all for your participation at Yersterday first Hide3D (temporary
> name) meeting.
> Theres was a lot of discussion and exchange,
> For those who had not the possibility to join; the log is available here:
> http://haxe.org/com/incubator/3dengine/log_6_12_2011
>
> I propose you guys to create entries on the domain you own, just to do
> basic, short documentation on what have been agreed and/or design choices
> for internal usage (on haxe wiki).
>
> (Nicolas, if you think this is abusing haxe's wiki, please tell us).
>
> In the end, what we agreed on was to make a first quick milestone; basically
> a cube and a camera controller (unreal like).
> It will help defining the interface with the different targets dans help the
> teams to work in parallel.

My two (euro) cents :

- focus on interoperability first, performances later

- ensure a common very-low-level API first (float buffers, textures,
shaders) and then build your logic on top of it : this way you'll only
have to maintain a small core of crossplatform features

- forget about structs or other language changes : use float buffers
which is the base for all modern 3D API (helps make the difference
between CPU and GPU memory)

The way I see it, you need to define a common wrapper API that will
target molehill, webgl, etc. and a shader language (HxSL ?) that will
target AGAL, GLSL, HLSL, etc.

After that you can start thinking about camera, animation, model
import/export etc. : every part of it will most likely be written once
in haXe and built on top of the low level API.

Good luck,
Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

sledorze
In reply to this post by Cauê W.
Hi Andy!

We missed you,

Having the possibility to use existing tools is a must have (we want to be able to bring artist to work with it).
Justin is pushing also for prefab;
I have no opinion yet, but I think it's better to have an open tool which is proven and scale well with data (you know.. sometimes you use big resolution meshes for characters because you back that in normal maps...)

About away3D / NME (two different subjects).
What you're mentionning has been discusses and here are the counter arguments to consider (I'm still open; a lot of people are coming back with those arguments, we'll cut it next week-end):

- Time to get something usable for a real product, porting importers which works with existing away3D api is probably faster (perhaps it is wrong).
- Need to tackle more than graphics (sound, network, controls, etc..).
- Flash will remain flash, so here we cannot rehack below it's interface (Stage3D).

What we agreed to consider for first Milestone is to just do a minimal port of what's needed (Justin has proposed to help), after this milestone, we'll be allowed to try things out (even throw, nothing is settled) and the backends could make progress.
Again, it's all about iterating faster; make it happen and then refine.

I think we should strive for one goal: being able to cross platform and import existing datas formats from tools, aside that, I'm fully open for the runtime.

Just thought it is sometimes nice to be able to get some people feel at home when using an engine. (on the other side, I would love to see some nicer way (DSL) to query the scenegraph for rad (did I mentionned Jquery style?).

In some times, we could split the project and try several approach (could become several projects).
Just think that we will have to do the full circle: release some real apps/games just to prove things out (even before we put all features you can find in an engine).

Stephane
Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

fintan boyle
" I think it's better to have an open tool which is
proven and scale well with data"

How about Blender?  
1:37:13 Richard Olsson - Blender in an Adobe Flash workflow:
http://www.youtube.com/watch?v=8BuLLGZ69VE


On Mon, Jun 13, 2011 at 10:56 AM, sledorze <[hidden email]> wrote:
Hi Andy!

We missed you,

Having the possibility to use existing tools is a must have (we want to be
able to bring artist to work with it).
Justin is pushing also for prefab;
I have no opinion yet, but I think it's better to have an open tool which is
proven and scale well with data (you know.. sometimes you use big resolution
meshes for characters because you back that in normal maps...)

About away3D / NME (two different subjects).
What you're mentionning has been discusses and here are the counter
arguments to consider (I'm still open; a lot of people are coming back with
those arguments, we'll cut it next week-end):

- Time to get something usable for a real product, porting importers which
works with existing away3D api is probably faster (perhaps it is wrong).
- Need to tackle more than graphics (sound, network, controls, etc..).
- Flash will remain flash, so here we cannot rehack below it's interface
(Stage3D).

What we agreed to consider for first Milestone is to just do a minimal port
of what's needed (Justin has proposed to help), after this milestone, we'll
be allowed to try things out (even throw, nothing is settled) and the
backends could make progress.
Again, it's all about iterating faster; make it happen and then refine.

I think we should strive for one goal: being able to cross platform and
import existing datas formats from tools, aside that, I'm fully open for the
runtime.

Just thought it is sometimes nice to be able to get some people feel at home
when using an engine. (on the other side, I would love to see some nicer way
(DSL) to query the scenegraph for rad (did I mentionned Jquery style?).

In some times, we could split the project and try several approach (could
become several projects).
Just think that we will have to do the full circle: release some real
apps/games just to prove things out (even before we put all features you can
find in an engine).

Stephane


--
View this message in context: http://haxe.1354130.n2.nabble.com/3D-Engine-incubator-next-step-tp6469370p6469570.html
Sent from the Haxe mailing list archive at Nabble.com.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

sledorze
In reply to this post by sledorze
Ouch!
I meant... Cauê... :)
Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

sledorze
In reply to this post by Nicolas Cannasse
That's basically what Matthew's proposed and will do.

The difference being that at the same time, we want to progress on the high level and take advantage of existing tools / formats.. hence the proposition to stick to an existing interface and use glue until replacement/refactor (the primary reason for flash3D and using away3D importers / data structures - could be threejs, whatever)

I am not deaf to what people say and looks like many of you wanna get ride of using an existing interface.

Just think that working only one layer at a time will make use progress slower..

Stephane
Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

Matthew Spencer-2
In the meeting, we discussed implementing the low-level API based on Stage3D/Context3D since Away3D is based on Stage3D and it would require few changes. However, after looking at Stage3D more closely, it lacks some important performance based features. Not to mention that many of the functions add an extra step by wrapping things up in classes. No VAO support increases state changes and gl function calls.

I'm sorry that I did not bring this up in the meeting, but I had not looked extensively into Molehill recently. If we write the cross-platform API a bit closer to gl, we'll gain performance and flexability on non Molehill targets. Any native support that Molehill  lacks, can be emulated.

Please let me know what you think,
   --Matthew Spencer

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

sledorze
We need the VBOs access, so if they hide them, we got to bypass (oh god what are they doing???)
Thanks for brigging this up!
So got to define another layer, so on the high level side; this would mean plug between cross PF api and doing some glue with importers..

On Mon, Jun 13, 2011 at 3:14 PM, Matthew Spencer-2 [via Haxe] <[hidden email]> wrote:
In the meeting, we discussed implementing the low-level API based on Stage3D/Context3D since Away3D is based on Stage3D and it would require few changes. However, after looking at Stage3D more closely, it lacks some important performance based features. Not to mention that many of the functions add an extra step by wrapping things up in classes. No VAO support increases state changes and gl function calls.

I'm sorry that I did not bring this up in the meeting, but I had not looked extensively into Molehill recently. If we write the cross-platform API a bit closer to gl, we'll gain performance and flexability on non Molehill targets. Any native support that Molehill  lacks, can be emulated.

Please let me know what you think,
   --Matthew Spencer

--
haXe - an open source web programming language
http://haxe.org


If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/3D-Engine-incubator-next-step-tp6469370p6470092.html
To unsubscribe from 3D Engine incubator - next step., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

sledorze
In reply to this post by Matthew Spencer-2
Keep in mind that Stage3D is still a target, so the interface will have to be able to work on top of with for flash.

On Mon, Jun 13, 2011 at 3:20 PM, Stephane Le Dorze <[hidden email]> wrote:
We need the VBOs access, so if they hide them, we got to bypass (oh god what are they doing???)
Thanks for brigging this up!
So got to define another layer, so on the high level side; this would mean plug between cross PF api and doing some glue with importers..


On Mon, Jun 13, 2011 at 3:14 PM, Matthew Spencer-2 [via Haxe] <[hidden email]> wrote:
In the meeting, we discussed implementing the low-level API based on Stage3D/Context3D since Away3D is based on Stage3D and it would require few changes. However, after looking at Stage3D more closely, it lacks some important performance based features. Not to mention that many of the functions add an extra step by wrapping things up in classes. No VAO support increases state changes and gl function calls.

I'm sorry that I did not bring this up in the meeting, but I had not looked extensively into Molehill recently. If we write the cross-platform API a bit closer to gl, we'll gain performance and flexability on non Molehill targets. Any native support that Molehill  lacks, can be emulated.

Please let me know what you think,
   --Matthew Spencer

--
haXe - an open source web programming language
http://haxe.org


If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/3D-Engine-incubator-next-step-tp6469370p6470092.html
To unsubscribe from 3D Engine incubator - next step., click here.



--
Stéphane Le Dorze

Tel: <a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="+33608767015" target="_blank">+33 (0) 6 08  76 70 15





--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

Dion Whitehead Amago
In reply to this post by Cauê W.
> I'd take off any reference to the flash api.

+1

Dion Amago

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

Matthew Spencer-2
They hide VAO access. Not VBO access.
--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

sledorze
oh.. anyway it's somewhat a comparable issue..

On Mon, Jun 13, 2011 at 3:40 PM, Matthew Spencer-2 [via Haxe] <[hidden email]> wrote:
They hide VAO access. Not VBO access.
--
haXe - an open source web programming language
http://haxe.org


If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/3D-Engine-incubator-next-step-tp6469370p6470181.html
To unsubscribe from 3D Engine incubator - next step., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

Nicolas Cannasse
In reply to this post by Matthew Spencer-2
Le 13/06/2011 15:13, Matthew Spencer a écrit :

> In the meeting, we discussed implementing the low-level API based on
> Stage3D/Context3D since Away3D is based on Stage3D and it would require
> few changes. However, after looking at Stage3D more closely, it lacks
> some important performance based features. Not to mention that many of
> the functions add an extra step by wrapping things up in classes. No VAO
> support increases state changes and gl function calls.
>
> I'm sorry that I did not bring this up in the meeting, but I had not
> looked extensively into Molehill recently. If we write the
> cross-platform API a bit closer to gl, we'll gain performance and
> flexability on non Molehill targets. Any native support that Molehill
>   lacks, can be emulated.

I think that Stage3D is low level and abstract enough to be a good
starting base. You can upload data to GPU through buffers/textures and
manipulate it with shaders. period.

Emulating the "good-old" GL functions when you create buffers on-the-fly
from code with glVertex and friends is just no longer a good/efficient
way to do 3D

As for wrapper classes : as long as it's per-buffer (and not per-vertex)
it's fine, and if you need to make a lot of API calls you can still
inline the methods.

That's for the low-level stuff.

High-level layer can build a lot of different things on top of it, and
eventually use some medium-layer abstractions that use fast-paths on
some particular platforms.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

Matthew Spencer-2
I think that Stage3D is low level and abstract enough to be a good starting base. You can upload data to GPU through buffers/textures and manipulate it with shaders. period.
It is, just misses a few basic things.
  
Emulating the "good-old" GL functions when you create buffers on-the-fly from code with glVertex and friends is just no longer a good/efficient way to do 3D
Oh, no. I've never had any intention to do this at all. The only way this will be done is if I'm asked to implement OpenGL 1.0 support, which does not have the ability to utilize DMA, or buffers. Even virtualbox VM's without 3D acceleration have access to OpenGL 1.1 though, so I doubt 1.0 support will ever be needed.
  
As for wrapper classes : as long as it's per-buffer (and not per-vertex) it's fine, and if you need to make a lot of API calls you can still inline the methods.
As said above, nothing will be per vertex. VAO support would be nice to have for reducing calls, which is why I brought up implementing some extra features from the GL featureset into the API.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: 3D Engine incubator - next step.

Gamehaxe
In reply to this post by Nicolas Cannasse
Yes, I highly recommend first getting it working with flash.
Starting with a well-defined API is over half your work done.
The Stage3D API is much smaller than the Stage 2D stuff, so emulating
the API in JS should be very doable. And what is more, it splits
the project off into a separate job, which can succeed or fail on
its own.  That is to say, if the JS side works, but the rest fails,
or the other way around, you are still left with something good.
If you write "The new API to kill all other APIs", and you do not
actually finish it, you are left with nothing.
Alternatively, you could choose the JS low level implementation
as fixed, and write an adapter class for flash - much the same
benefits if you think the JS API is as well defined.
If you do not limit your scope, the project will vanish into thin air.

Get it working.

Then you profile.

Then you optimise.

.. cross-platform API a bit closer to gl ..
I think you will find that the molehill API is VERY close to
"best practice opengl".

It is easy to add a "native tunnel" in NME and fit it in generally
with the existing API if you want a fast way of doing things -
eg nme.display.Graphics.drawTiles.  You could always do something
similar with opengl, but honestly I don't think you will have to.

Hugh



--
haXe - an open source web programming language
http://haxe.org