HxQuake: Quake2-based 3D renderer for flash

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

HxQuake: Quake2-based 3D renderer for flash

Iain Surgey
Hey everyone,

After months of work I'm finally releasing this 3D engine. It seems to give good performance on most machines it's been tested on, especially considering the level of detail.

It is still work in progress so do not expect to have a fully functioning engine if you checkout the source code. Think of this version as a 'proof of concept' to show that these software rendering techniques could potentially be used to create fast-paced 3D content for the flash platform. However there is much work to be done to turn this into a more general purpose, feature complete 3D engine for building interactive content, and more performance optimizations to come

Known Issues:
- Error #1506. This seems to happen sometimes particularly when using 10.1 beta 1&2 (beta 3 may fix it).
- Sometimes the animated model bugs out. This is a glitch in the animation code which was only added very recently.
- A few of the textures aren't aligned correctly.
- Sometimes the lightmaps aren't applied correctly.

If you discover any issues not listed here, let me know.

Here are the links:
Google code : http://code.google.com/p/hxquake/
Screenshots : http://hxquake.appspot.com/html/images.html
Demo (9mb) : http://hxquake.appspot.com/html/index.html

Feedback is welcome. Any questions, ask away :)

Iain.

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

Re: HxQuake: Quake2-based 3D renderer for flash

Lee Sylvester
That's bloody awesome. Really shows what Flash is capable of if you have
the knowhow.

Well done!

Lee




Iain Surgey wrote:

> Hey everyone,
>
> After months of work I'm finally releasing this 3D engine. It seems to
> give good performance on most machines it's been tested on, especially
> considering the level of detail.
> It is still work in progress so do not expect to have a fully
> functioning engine if you checkout the source code. Think of this
> version as a 'proof of concept' to show that these software rendering
> techniques could potentially be used to create fast-paced 3D content
> for the flash platform. However there is much work to be done to turn
> this into a more general purpose, feature complete 3D engine for
> building interactive content, and more performance optimizations to come
>
> Known Issues:
> - Error #1506. This seems to happen sometimes particularly when using
> 10.1 beta 1&2 (beta 3 may fix it).
> - Sometimes the animated model bugs out. This is a glitch in the
> animation code which was only added very recently.
> - A few of the textures aren't aligned correctly.
> - Sometimes the lightmaps aren't applied correctly.
>
> If you discover any issues not listed here, let me know.
>
> Here are the links:
> Google code : http://code.google.com/p/hxquake/
> Screenshots : http://hxquake.appspot.com/html/images.html
> Demo (9mb) : http://hxquake.appspot.com/html/index.html
>
> Feedback is welcome. Any questions, ask away :)
>
> Iain.


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

Re: HxQuake: Quake2-based 3D renderer for flash

Justin Donaldson
In reply to this post by Iain Surgey
That's very impressive.  Great work so far!

-Justin

On Sat, Feb 27, 2010 at 6:44 PM, Iain Surgey <[hidden email]> wrote:
Hey everyone,

After months of work I'm finally releasing this 3D engine. It seems to give good performance on most machines it's been tested on, especially considering the level of detail.

It is still work in progress so do not expect to have a fully functioning engine if you checkout the source code. Think of this version as a 'proof of concept' to show that these software rendering techniques could potentially be used to create fast-paced 3D content for the flash platform. However there is much work to be done to turn this into a more general purpose, feature complete 3D engine for building interactive content, and more performance optimizations to come

Known Issues:
- Error #1506. This seems to happen sometimes particularly when using 10.1 beta 1&2 (beta 3 may fix it).
- Sometimes the animated model bugs out. This is a glitch in the animation code which was only added very recently.
- A few of the textures aren't aligned correctly.
- Sometimes the lightmaps aren't applied correctly.

If you discover any issues not listed here, let me know.

Here are the links:
Google code : http://code.google.com/p/hxquake/
Screenshots : http://hxquake.appspot.com/html/images.html
Demo (9mb) : http://hxquake.appspot.com/html/index.html

Feedback is welcome. Any questions, ask away :)

Iain.

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



--
Justin Donaldson
PhD Candidate, Informatics
Indiana University
http://www.scwn.net
aim: iujjd
twitter: jjdonald

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

Re: HxQuake: Quake2-based 3D renderer for flash

Adrian Cowan
In reply to this post by Iain Surgey
Yeah wow,

That looks awesome,
But it took me a while to realise that down was mapped to 'z' on my keyboard not 'e'.

On my fathers 4Ghz Quadcore I was getting upto 47 FPS.
But I was even getting upto 7 FPS on my laptop (2.1 Dualcore).

Great job!

Adrian

On Sun, Feb 28, 2010 at 10:44 AM, Iain Surgey <[hidden email]> wrote:
Hey everyone,

After months of work I'm finally releasing this 3D engine. It seems to give good performance on most machines it's been tested on, especially considering the level of detail.

It is still work in progress so do not expect to have a fully functioning engine if you checkout the source code. Think of this version as a 'proof of concept' to show that these software rendering techniques could potentially be used to create fast-paced 3D content for the flash platform. However there is much work to be done to turn this into a more general purpose, feature complete 3D engine for building interactive content, and more performance optimizations to come

Known Issues:
- Error #1506. This seems to happen sometimes particularly when using 10.1 beta 1&2 (beta 3 may fix it).
- Sometimes the animated model bugs out. This is a glitch in the animation code which was only added very recently.
- A few of the textures aren't aligned correctly.
- Sometimes the lightmaps aren't applied correctly.

If you discover any issues not listed here, let me know.

Here are the links:
Google code : http://code.google.com/p/hxquake/
Screenshots : http://hxquake.appspot.com/html/images.html
Demo (9mb) : http://hxquake.appspot.com/html/index.html

Feedback is welcome. Any questions, ask away :)

Iain.

--
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: HxQuake: Quake2-based 3D renderer for flash

Yanis Benson
Hmmm... It's stable 14 FPS on my 1.6Ghz 1-core.

And yeah, great job!

On 02/28/2010 10:02 AM, Adrian Cowan wrote:
Yeah wow,

That looks awesome,
But it took me a while to realise that down was mapped to 'z' on my keyboard not 'e'.

On my fathers 4Ghz Quadcore I was getting upto 47 FPS.
But I was even getting upto 7 FPS on my laptop (2.1 Dualcore).

Great job!

Adrian

On Sun, Feb 28, 2010 at 10:44 AM, Iain Surgey <[hidden email]> wrote:
Hey everyone,

After months of work I'm finally releasing this 3D engine. It seems to give good performance on most machines it's been tested on, especially considering the level of detail.

It is still work in progress so do not expect to have a fully functioning engine if you checkout the source code. Think of this version as a 'proof of concept' to show that these software rendering techniques could potentially be used to create fast-paced 3D content for the flash platform. However there is much work to be done to turn this into a more general purpose, feature complete 3D engine for building interactive content, and more performance optimizations to come

Known Issues:
- Error #1506. This seems to happen sometimes particularly when using 10.1 beta 1&2 (beta 3 may fix it).
- Sometimes the animated model bugs out. This is a glitch in the animation code which was only added very recently.
- A few of the textures aren't aligned correctly.
- Sometimes the lightmaps aren't applied correctly.

If you discover any issues not listed here, let me know.

Here are the links:
Google code : http://code.google.com/p/hxquake/
Screenshots : http://hxquake.appspot.com/html/images.html
Demo (9mb) : http://hxquake.appspot.com/html/index.html

Feedback is welcome. Any questions, ask away :)

Iain.

--
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: HxQuake: Quake2-based 3D renderer for flash

Baluta Cristian
20fps on 1.83 mac intel, but i get even 1fps when i see the sky.

On Sun, Feb 28, 2010 at 9:29 AM, Yanis Benson <[hidden email]> wrote:
Hmmm... It's stable 14 FPS on my 1.6Ghz 1-core.

And yeah, great job!


On 02/28/2010 10:02 AM, Adrian Cowan wrote:
Yeah wow,

That looks awesome,
But it took me a while to realise that down was mapped to 'z' on my keyboard not 'e'.

On my fathers 4Ghz Quadcore I was getting upto 47 FPS.
But I was even getting upto 7 FPS on my laptop (2.1 Dualcore).

Great job!

Adrian

On Sun, Feb 28, 2010 at 10:44 AM, Iain Surgey <[hidden email]> wrote:
Hey everyone,

After months of work I'm finally releasing this 3D engine. It seems to give good performance on most machines it's been tested on, especially considering the level of detail.

It is still work in progress so do not expect to have a fully functioning engine if you checkout the source code. Think of this version as a 'proof of concept' to show that these software rendering techniques could potentially be used to create fast-paced 3D content for the flash platform. However there is much work to be done to turn this into a more general purpose, feature complete 3D engine for building interactive content, and more performance optimizations to come

Known Issues:
- Error #1506. This seems to happen sometimes particularly when using 10.1 beta 1&2 (beta 3 may fix it).
- Sometimes the animated model bugs out. This is a glitch in the animation code which was only added very recently.
- A few of the textures aren't aligned correctly.
- Sometimes the lightmaps aren't applied correctly.

If you discover any issues not listed here, let me know.

Here are the links:
Google code : http://code.google.com/p/hxquake/
Screenshots : http://hxquake.appspot.com/html/images.html
Demo (9mb) : http://hxquake.appspot.com/html/index.html

Feedback is welcome. Any questions, ask away :)

Iain.

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



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



--
Băluță Cristian
http://ralcr.com
http://imagin.ro

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

Re: HxQuake: Quake2-based 3D renderer for flash

Franco Ponticelli
In reply to this post by Iain Surgey
Amazing! Congratulations.

Franco

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

Re: HxQuake: Quake2-based 3D renderer for flash

Tony Polinelli
Amazing indeed- and looking at the code i have absolutely NO idea
where how it works ;P

it barely looks like haxe with all of the preprocessing, python etc.
very wierd setup you're using there. - but it seems to be working for
you!

congrats


On Sun, Feb 28, 2010 at 8:24 PM, Franco Ponticelli
<[hidden email]> wrote:
> Amazing! Congratulations.
>
> Franco
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
Tony Polinelli
http://touchmypixel.com

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

Re: HxQuake: Quake2-based 3D renderer for flash

Nicolas Cannasse
In reply to this post by Iain Surgey
Iain Surgey a écrit :

> Hey everyone,
>
> After months of work I'm finally releasing this 3D engine. It seems to
> give good performance on most machines it's been tested on, especially
> considering the level of detail.
>
> It is still work in progress so do not expect to have a fully
> functioning engine if you checkout the source code. Think of this
> version as a 'proof of concept' to show that these software rendering
> techniques could potentially be used to create fast-paced 3D content for
> the flash platform. However there is much work to be done to turn this
> into a more general purpose, feature complete 3D engine for building
> interactive content, and more performance optimizations to come

Looks great ;)

But due to the amount of preprocessing, I don't think we can call it
haXe-based anymore ;)

Best,
Nicolas

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

Re: HxQuake: Quake2-based 3D renderer for flash

Iain Surgey

But due to the amount of preprocessing, I don't think we can call it haXe-based anymore ;)


If there is some sort of problem attributing this project to haxe, that's fine; I'll remove all references and links, change the name, and that will be that.

To be honest I've been planning for a while to port this back to C and use it with Alchemy. As Tony Polinelli points out, unless someone is familiar with the pre-processor statements and how it works they might struggle to work with the codebase.

The only reason I didn't use alchemy from the start is it didn't occur to me when I first investigated that I could pass a pointer back to AS3 which references the screen buffer in applicationDomain.domainMemory for drawing to the bitmap. That, and I liked the idea of retaining the full flash API while still using the fast memory opcodes. But for code readability pure C would be better.

I have updated the demo swf which seems to fix the bug in the model animation, and now the user can fly outside the map without freezing. There is also a lower resolution version (640x480) available here : http://hxquake.appspot.com/html/index640.html
This gives much better performance for those who were struggling with 800x600.

Also, the input instructions have been corrected for the Down (Z) key. Sorry about that.

Iain

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

Re: HxQuake: Quake2-based 3D renderer for flash

Nicolas Cannasse
Iain Surgey a écrit :
>
>     But due to the amount of preprocessing, I don't think we can call it
>     haXe-based anymore ;)
>
>
> If there is some sort of problem attributing this project to haxe,
> that's fine; I'll remove all references and links, change the name, and
> that will be that.

Don't worry, that's not a problem at all. I was not meaning that it's an
issue, I was just surprised while looking at the sources ;)

Best,
Nicolas

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

Re: HxQuake: Quake2-based 3D renderer for flash

Iain Surgey
Oh, sorry for being so abrupt in that case. I mis-interpreted what you said.

Yes, it is very unlike a normal haxe project what with all the preprocessing, and all code is marshalled into a single class with no OOP. Perhaps the planned macro feature could be used to remove the need for a preprocessor, but I think probably the best option is to use Alchemy for the underlying renderer, and a proper Haxe-like API could be written on top to make use of it. I did write a haxe class for flash.Memory which allowed for C structs, arrays and pointers, but believe it or not it was even harder to read than the preprocessor statements.

Anyways, thanks everyone for the positive feedback. There is (hopefully) a lot more to come from this :)

P.S I'm 93% through the Google Appengine daily quota so the demo/screenshot links will probably be unavailable very soon. The next quota reset is in 17 hours.

Iain

On 28 February 2010 14:03, Nicolas Cannasse <[hidden email]> wrote:
Don't worry, that's not a problem at all. I was not meaning that it's an issue, I was just surprised while looking at the sources ;)


Best,
Nicolas

--
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: HxQuake: Quake2-based 3D renderer for flash

makc
On Sun, Feb 28, 2010 at 4:30 PM, Iain Surgey <[hidden email]> wrote:
> P.S I'm 93% through the Google Appengine daily quota so the demo/screenshot
> links will probably be unavailable very soon. The next quota reset is in 17

in the mean time there are sites like xs.to ;) ;)

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

Re: HxQuake: Quake2-based 3D renderer for flash

Iain Surgey
That particular site doesn't seem to support swf. But thanks for the suggestion - I found megaswf.com and uploaded it there.

640x480: http://megaswf.com/view/88f9447a52966d626b2b00ef4022c0c2.html
800x600: http://megaswf.com/view/505300aa4187baf07022884681a03f40.html

Cheers,
Iain

On 28 February 2010 17:31, Makc <[hidden email]> wrote:
On Sun, Feb 28, 2010 at 4:30 PM, Iain Surgey <[hidden email]> wrote:
> P.S I'm 93% through the Google Appengine daily quota so the demo/screenshot
> links will probably be unavailable very soon. The next quota reset is in 17

in the mean time there are sites like xs.to ;) ;)

--
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: HxQuake: Quake2-based 3D renderer for flash

back2dos
In reply to this post by Iain Surgey
Hi Iain,

looks quite impressive ... :)
now my question is, how does this compare to the flash 3D engines that
are already around?
how many polys are there, or on what other plain should they be compared?
Can this approach provide more performance for certain scenarios?

greetz
back2dos

> Hey everyone,
>
> After months of work I'm finally releasing this 3D engine. It seems to
> give good performance on most machines it's been tested on, especially
> considering the level of detail.
>
> It is still work in progress so do not expect to have a fully
> functioning engine if you checkout the source code. Think of this
> version as a 'proof of concept' to show that these software rendering
> techniques could potentially be used to create fast-paced 3D content
> for the flash platform. However there is much work to be done to turn
> this into a more general purpose, feature complete 3D engine for
> building interactive content, and more performance optimizations to come
>
> Known Issues:
> - Error #1506. This seems to happen sometimes particularly when using
> 10.1 beta 1&2 (beta 3 may fix it).
> - Sometimes the animated model bugs out. This is a glitch in the
> animation code which was only added very recently.
> - A few of the textures aren't aligned correctly.
> - Sometimes the lightmaps aren't applied correctly.
>
> If you discover any issues not listed here, let me know.
>
> Here are the links:
> Google code : http://code.google.com/p/hxquake/
> Screenshots : http://hxquake.appspot.com/html/images.html
> Demo (9mb) : http://hxquake.appspot.com/html/index.html
>
> Feedback is welcome. Any questions, ask away :)
>
> Iain.


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

Re: HxQuake: Quake2-based 3D renderer for flash

Iain Surgey
> now my question is, how does this compare to the flash 3D engines that are already around?

That's a difficult comparison to make since it uses very different techniques to engines like Papervision and Sandy.

For instance, those libraries only render triangles and often have a considerable amount of overdraw in the places on screen they overlap (maybe one of the devs will correct me though - I imagine they have some sort of occlusion culling). hxQuake uses polygons which may have greater than 3 sides. Before drawing the polygons, the edges are placed into a linked "edge list" and sorted from left-to-right, top-to-bottom. From this edge list 'spans' can be generated, which are just horizontal lines representing where to draw on the screen. This process completely eliminates overdraw, which is a significant performance-killer, particularly in software rendering.

Another difference is in the texture application. The current 3D engines use the in-built flash drawing API to apply textures, which can look a lot smoother but is also a lot more resource intensive than the quake method which only calculates the image perspective info every 16 pixels (and this is usually not noticable) and uses mip-mapping instead of on-the-fly texture scaling.

The best comparison would probably be a superficial one, i.e "how does it look?" and "how smooth does it run?", but if you want I will make a polygon counter which will display the currently visible polygons on the screen (though you would need an equivelant counter on the engine you wish to compare - note it should not count all polygons, only those currently displayed and not occluded/out of the view frustum).

> Can this approach provide more performance for certain scenarios?

The best scenarios would in densely-occluded environments, such as closed rooms rather than vast, complex outdoor scenes. There is a technique used in quake called "Potentially Visible Set" (PVS) which can quickly determine visible polygons and skip processing the rest, which gives it a performance advantage in these situations. In the demo, if you fly outside the closed map area you will notice a performance drop. This is because there is no visibility information to process in that part of the map.

Hope this helps.

Iain

On 28 February 2010 19:24, Juraj Kirchheim <[hidden email]> wrote:
Hi Iain,

looks quite impressive ... :)
now my question is, how does this compare to the flash 3D engines that are already around?
how many polys are there, or on what other plain should they be compared?
Can this approach provide more performance for certain scenarios?

greetz
back2dos

Hey everyone,

After months of work I'm finally releasing this 3D engine. It seems to give good performance on most machines it's been tested on, especially considering the level of detail.

It is still work in progress so do not expect to have a fully functioning engine if you checkout the source code. Think of this version as a 'proof of concept' to show that these software rendering techniques could potentially be used to create fast-paced 3D content for the flash platform. However there is much work to be done to turn this into a more general purpose, feature complete 3D engine for building interactive content, and more performance optimizations to come

Known Issues:
- Error #1506. This seems to happen sometimes particularly when using 10.1 beta 1&2 (beta 3 may fix it).
- Sometimes the animated model bugs out. This is a glitch in the animation code which was only added very recently.
- A few of the textures aren't aligned correctly.
- Sometimes the lightmaps aren't applied correctly.

If you discover any issues not listed here, let me know.

Here are the links:
Google code : http://code.google.com/p/hxquake/
Screenshots : http://hxquake.appspot.com/html/images.html
Demo (9mb) : http://hxquake.appspot.com/html/index.html

Feedback is welcome. Any questions, ask away :)

Iain.


--
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: HxQuake: Quake2-based 3D renderer for flash

makc
In reply to this post by Iain Surgey
On Sun, Feb 28, 2010 at 8:15 PM, Iain Surgey <[hidden email]> wrote:
> That particular site doesn't seem to support swf. But thanks for the
> suggestion - I found megaswf.com and uploaded it there.
>
> 640x480: http://megaswf.com/view/88f9447a52966d626b2b00ef4022c0c2.html
> 800x600: http://megaswf.com/view/505300aa4187baf07022884681a03f40.html

I was thinking more like about screenshots, but now that my torrents
arrived, I can use full bandwidth :)

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

Re: HxQuake: Quake2-based 3D renderer for flash

jlm@justinfront.net
In reply to this post by Iain Surgey
Wow Ian cool stuff.

From a basic wanting to try it out could either the sandy3d or away3dlite collada parser be modified to work with it... I mean all that pre processing does that make it impossible to load models on the fly?

Ideally if it can run the sandy3d dice example using similar collada files and material loaded at run time, then it would be easier for people to use, in its current form it seems very complex to use but really amazing stuff all the same. 


On 28 Feb 2010, at 20:12, Iain Surgey wrote:

> now my question is, how does this compare to the flash 3D engines that are already around?

That's a difficult comparison to make since it uses very different techniques to engines like Papervision and Sandy.

For instance, those libraries only render triangles and often have a considerable amount of overdraw in the places on screen they overlap (maybe one of the devs will correct me though - I imagine they have some sort of occlusion culling). hxQuake uses polygons which may have greater than 3 sides. Before drawing the polygons, the edges are placed into a linked "edge list" and sorted from left-to-right, top-to-bottom. From this edge list 'spans' can be generated, which are just horizontal lines representing where to draw on the screen. This process completely eliminates overdraw, which is a significant performance-killer, particularly in software rendering.

Another difference is in the texture application. The current 3D engines use the in-built flash drawing API to apply textures, which can look a lot smoother but is also a lot more resource intensive than the quake method which only calculates the image perspective info every 16 pixels (and this is usually not noticable) and uses mip-mapping instead of on-the-fly texture scaling.

The best comparison would probably be a superficial one, i.e "how does it look?" and "how smooth does it run?", but if you want I will make a polygon counter which will display the currently visible polygons on the screen (though you would need an equivelant counter on the engine you wish to compare - note it should not count all polygons, only those currently displayed and not occluded/out of the view frustum).

> Can this approach provide more performance for certain scenarios?

The best scenarios would in densely-occluded environments, such as closed rooms rather than vast, complex outdoor scenes. There is a technique used in quake called "Potentially Visible Set" (PVS) which can quickly determine visible polygons and skip processing the rest, which gives it a performance advantage in these situations. In the demo, if you fly outside the closed map area you will notice a performance drop. This is because there is no visibility information to process in that part of the map.

Hope this helps.

Iain

On 28 February 2010 19:24, Juraj Kirchheim <[hidden email]> wrote:
Hi Iain,

looks quite impressive ... :)
now my question is, how does this compare to the flash 3D engines that are already around?
how many polys are there, or on what other plain should they be compared?
Can this approach provide more performance for certain scenarios?

greetz
back2dos

Hey everyone,

After months of work I'm finally releasing this 3D engine. It seems to give good performance on most machines it's been tested on, especially considering the level of detail.

It is still work in progress so do not expect to have a fully functioning engine if you checkout the source code. Think of this version as a 'proof of concept' to show that these software rendering techniques could potentially be used to create fast-paced 3D content for the flash platform. However there is much work to be done to turn this into a more general purpose, feature complete 3D engine for building interactive content, and more performance optimizations to come

Known Issues:
- Error #1506. This seems to happen sometimes particularly when using 10.1 beta 1&2 (beta 3 may fix it).
- Sometimes the animated model bugs out. This is a glitch in the animation code which was only added very recently.
- A few of the textures aren't aligned correctly.
- Sometimes the lightmaps aren't applied correctly.

If you discover any issues not listed here, let me know.

Here are the links:
Google code : http://code.google.com/p/hxquake/
Screenshots : http://hxquake.appspot.com/html/images.html
Demo (9mb) : http://hxquake.appspot.com/html/index.html

Feedback is welcome. Any questions, ask away :)

Iain.


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

--
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: HxQuake: Quake2-based 3D renderer for flash

jlm@justinfront.net
Sorry I don't know much about quake, I was just asking in terms of how I use flash 3d engines currently, so realize it may not be possible, but wondered.

On 28 Feb 2010, at 20:28, Justin Lawerance Mills wrote:

Wow Ian cool stuff.

From a basic wanting to try it out could either the sandy3d or away3dlite collada parser be modified to work with it... I mean all that pre processing does that make it impossible to load models on the fly?

Ideally if it can run the sandy3d dice example using similar collada files and material loaded at run time, then it would be easier for people to use, in its current form it seems very complex to use but really amazing stuff all the same. 


On 28 Feb 2010, at 20:12, Iain Surgey wrote:

> now my question is, how does this compare to the flash 3D engines that are already around?

That's a difficult comparison to make since it uses very different techniques to engines like Papervision and Sandy.

For instance, those libraries only render triangles and often have a considerable amount of overdraw in the places on screen they overlap (maybe one of the devs will correct me though - I imagine they have some sort of occlusion culling). hxQuake uses polygons which may have greater than 3 sides. Before drawing the polygons, the edges are placed into a linked "edge list" and sorted from left-to-right, top-to-bottom. From this edge list 'spans' can be generated, which are just horizontal lines representing where to draw on the screen. This process completely eliminates overdraw, which is a significant performance-killer, particularly in software rendering.

Another difference is in the texture application. The current 3D engines use the in-built flash drawing API to apply textures, which can look a lot smoother but is also a lot more resource intensive than the quake method which only calculates the image perspective info every 16 pixels (and this is usually not noticable) and uses mip-mapping instead of on-the-fly texture scaling.

The best comparison would probably be a superficial one, i.e "how does it look?" and "how smooth does it run?", but if you want I will make a polygon counter which will display the currently visible polygons on the screen (though you would need an equivelant counter on the engine you wish to compare - note it should not count all polygons, only those currently displayed and not occluded/out of the view frustum).

> Can this approach provide more performance for certain scenarios?

The best scenarios would in densely-occluded environments, such as closed rooms rather than vast, complex outdoor scenes. There is a technique used in quake called "Potentially Visible Set" (PVS) which can quickly determine visible polygons and skip processing the rest, which gives it a performance advantage in these situations. In the demo, if you fly outside the closed map area you will notice a performance drop. This is because there is no visibility information to process in that part of the map.

Hope this helps.

Iain

On 28 February 2010 19:24, Juraj Kirchheim <[hidden email]> wrote:
Hi Iain,

looks quite impressive ... :)
now my question is, how does this compare to the flash 3D engines that are already around?
how many polys are there, or on what other plain should they be compared?
Can this approach provide more performance for certain scenarios?

greetz
back2dos

Hey everyone,

After months of work I'm finally releasing this 3D engine. It seems to give good performance on most machines it's been tested on, especially considering the level of detail.

It is still work in progress so do not expect to have a fully functioning engine if you checkout the source code. Think of this version as a 'proof of concept' to show that these software rendering techniques could potentially be used to create fast-paced 3D content for the flash platform. However there is much work to be done to turn this into a more general purpose, feature complete 3D engine for building interactive content, and more performance optimizations to come

Known Issues:
- Error #1506. This seems to happen sometimes particularly when using 10.1 beta 1&2 (beta 3 may fix it).
- Sometimes the animated model bugs out. This is a glitch in the animation code which was only added very recently.
- A few of the textures aren't aligned correctly.
- Sometimes the lightmaps aren't applied correctly.

If you discover any issues not listed here, let me know.

Here are the links:
Google code : http://code.google.com/p/hxquake/
Screenshots : http://hxquake.appspot.com/html/images.html
Demo (9mb) : http://hxquake.appspot.com/html/index.html

Feedback is welcome. Any questions, ask away :)

Iain.


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

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

--
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: HxQuake: Quake2-based 3D renderer for flash

Iain Surgey
In reply to this post by jlm@justinfront.net
> I mean all that pre processing does that make it impossible to load models on the fly?

Compiling the BSP and converting the UV data at runtime would be fairly trivial. The PVS takes a loooong time to generate so that's not such a good idea. Though I am working on a significant overhaul to most of the stock quake2 stuff which would entirely replace the PVS for occlusion culling and completely bypass the edge sorting and span generation stages (but also retain zero-overdraw). It's too early to determine if these ideas will pan out though. If they do, a collada parser would be a great addition to the engine, though it might be a better idea to do that conversion offline with custom tools. It would still be supporting collada, just not directly in the client. Even if they don't, the engine still works pretty well without PVS (I think the performance drop is about 10-20%)

For now, content can be created using GtkRadiant (available at http://www.qeradiant.com/ ). Blender actually supports exporting .blend files to GtkRadiant, but this is sometimes a little buggy in my experience.

I've decided future developments will be in pure C, compiled with alchemy and with an easy-to-use haxe API to access and control the engine's functions. This means there won't be any significant updates until I get everything ported to the new build system.

On 28 February 2010 20:28, Justin Lawerance Mills <[hidden email]> wrote:
Wow Ian cool stuff.

From a basic wanting to try it out could either the sandy3d or away3dlite collada parser be modified to work with it... I mean all that pre processing does that make it impossible to load models on the fly?

Ideally if it can run the sandy3d dice example using similar collada files and material loaded at run time, then it would be easier for people to use, in its current form it seems very complex to use but really amazing stuff all the same. 


On 28 Feb 2010, at 20:12, Iain Surgey wrote:

> now my question is, how does this compare to the flash 3D engines that are already around?

That's a difficult comparison to make since it uses very different techniques to engines like Papervision and Sandy.

For instance, those libraries only render triangles and often have a considerable amount of overdraw in the places on screen they overlap (maybe one of the devs will correct me though - I imagine they have some sort of occlusion culling). hxQuake uses polygons which may have greater than 3 sides. Before drawing the polygons, the edges are placed into a linked "edge list" and sorted from left-to-right, top-to-bottom. From this edge list 'spans' can be generated, which are just horizontal lines representing where to draw on the screen. This process completely eliminates overdraw, which is a significant performance-killer, particularly in software rendering.

Another difference is in the texture application. The current 3D engines use the in-built flash drawing API to apply textures, which can look a lot smoother but is also a lot more resource intensive than the quake method which only calculates the image perspective info every 16 pixels (and this is usually not noticable) and uses mip-mapping instead of on-the-fly texture scaling.

The best comparison would probably be a superficial one, i.e "how does it look?" and "how smooth does it run?", but if you want I will make a polygon counter which will display the currently visible polygons on the screen (though you would need an equivelant counter on the engine you wish to compare - note it should not count all polygons, only those currently displayed and not occluded/out of the view frustum).

> Can this approach provide more performance for certain scenarios?

The best scenarios would in densely-occluded environments, such as closed rooms rather than vast, complex outdoor scenes. There is a technique used in quake called "Potentially Visible Set" (PVS) which can quickly determine visible polygons and skip processing the rest, which gives it a performance advantage in these situations. In the demo, if you fly outside the closed map area you will notice a performance drop. This is because there is no visibility information to process in that part of the map.

Hope this helps.

Iain

On 28 February 2010 19:24, Juraj Kirchheim <[hidden email]> wrote:
Hi Iain,

looks quite impressive ... :)
now my question is, how does this compare to the flash 3D engines that are already around?
how many polys are there, or on what other plain should they be compared?
Can this approach provide more performance for certain scenarios?

greetz
back2dos

Hey everyone,

After months of work I'm finally releasing this 3D engine. It seems to give good performance on most machines it's been tested on, especially considering the level of detail.

It is still work in progress so do not expect to have a fully functioning engine if you checkout the source code. Think of this version as a 'proof of concept' to show that these software rendering techniques could potentially be used to create fast-paced 3D content for the flash platform. However there is much work to be done to turn this into a more general purpose, feature complete 3D engine for building interactive content, and more performance optimizations to come

Known Issues:
- Error #1506. This seems to happen sometimes particularly when using 10.1 beta 1&2 (beta 3 may fix it).
- Sometimes the animated model bugs out. This is a glitch in the animation code which was only added very recently.
- A few of the textures aren't aligned correctly.
- Sometimes the lightmaps aren't applied correctly.

If you discover any issues not listed here, let me know.

Here are the links:
Google code : http://code.google.com/p/hxquake/
Screenshots : http://hxquake.appspot.com/html/images.html
Demo (9mb) : http://hxquake.appspot.com/html/index.html

Feedback is welcome. Any questions, ask away :)

Iain.


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

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


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


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