A Flash Developer Resource Site

Page 4 of 7 FirstFirst 1234567 LastLast
Results 61 to 80 of 131

Thread: [WIP] Flash quake/descent style renderer.

  1. #61
    Script kiddie VENGEANCE MX's Avatar
    Join Date
    Jun 2004
    Location
    England
    Posts
    2,590
    Blimey that's impressive. And I'm getting 60 fps here on my Intel Core 2 Duo 2.4 GHz iMac, 2GB RAM.
    http://www.birchlabs.co.uk/
    You know you want to.

  2. #62
    FK founder & general loiterer Flashkit's Avatar
    Join Date
    Feb 2000
    Location
    Sydney
    Posts
    1,149
    awesome.
    Regards Mark Fennell - Flash Kit Founder, general loiterer
    -------------------------------
    I Hate Zombies - iPhone Game | markfennell.com

  3. #63
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    Update to renderer part today.

    Although the ability to tile textures is a planned feature for graphics.drawTriangles, it's not yet implemented in the beta AFAIK. Back in post #53, I had already coded up a workaround: with some uv fiddling and bitmapData.copypixels, the small 64x64 textures are tiled in an auxiliary bitmapData which is then fed into drawTriangles, pretiled. That's the reason these demos consume so much memory - every polygon is doing this individually, so there's a _lot_ of copies of that 64x64 texture floating around.

    This might not be such a bad idea though, because it lets you composite other artwork (bulletholes, liquid splatters, damage) and make a more interactive environment. I'm finding that another good use for this surface is it's a handy place to pre-alpha-blend your textures with black in order to fake a lighting model.

    After probing into that idea, I think it's a big winner. For each cell, the user will be able to tag one lighting origin. Right now just the centroid of the cell is used. When the surface bitmap is tiled up from atomic textures, the texture is mixed with black using a basic falloff with radial distance. What's nice is that one omnidirectional light source will yield a simple circular highlight on the surface. This can be rendered quickly into a sprite as a radial gradient fill, then use bitmapData.draw to composite that sprite onto the surface texture. A second pass, with a bit more math involved, models the deep shadows that should be cast on cell walls by brush surfaces. Raycast points onto the cell surface, starting from the light source and passing through the brush vertices. Compute the convex hull of these points in 2D (this is fast), and then soften with a blurfilter to make the shadow boundary more gradual.

    Here's a scene without lighting:



    Here's what it looks like with lighting and white paint everywhere:



    Here's what the real lit scene looks like:



    Has a lot more life to it, I think!

    If the light origin doesn't move, the lights don't change, and there is zero runtime expense for doing this. Currently every surface is built when the map is instantiated, and hangs around forever. Even that initial step is very quick. Ultimately, there will be a need to dispose of these surface bitmaps when they are no longer in the scene, to reduce the memory usage from what it is now (which is too high IMO). Once this caching system is in place, there will be modest runtime expense, whenever a surface needs to be rebuilt for rendering but is currently in the disposed state. But when you amortize that cost over however many frames it continues to be used, it's effectively a very small penalty. All in all, this is very similar to how quake 1 did it's lighting ( http://www.bluesnews.com/abrash/chap68.shtml )

    Other random changes:
    * hitscan weapons are supported, you can put bulletholes in the walls
    * redid collision detection (again!) for greater robustness

    Up next:
    * adding physics attributes, basic particle rendering & updating (thinking of the wall-sparks from doom-a-like)
    * graduation (!)

  4. #64
    Student
    Join Date
    Apr 2001
    Location
    -
    Posts
    4,756
    hmm I think I just peed my pants

    is it possible to see a screenshot with the shadow casting and textures but without the face surrounding lines?
    Also on what tools do you currently rely,- is there any compatibility with existing hexen or alike BSP editors? - or for the enemies perhaps some 3d data format. Or do you perhaps need some 3d exporter?

  5. #65
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    Thanks for the feedback render, glad you liked (you guys too, FK & V_MX).

    Here's a screenshot w/o the lines for comparison. I like the added sharpness that the lines callout (especially on flat shaded objects) but on a textured surface they might be a little overkill.



    Right now, the only supported content creation tool is the map editor that was featured on&off in this thread. I am wishing I had learned an existing 3D tool, and worked on a good export/import pipe, instead of rolling something from scratch (but writing the editor was a good learning experience too I guess). I probably won't support the editors of any other games, but writing an export tool from one of the existing general purpose 3D editors might be a goal far in the future (something free - blender or that caligari program perhaps). I am comfortable using the homebrew tool but it is an unfortunate barrier for collaboration with other developers.

    Exporting enemies is a more tractable idea because you don't have to build all the portal information - they're just a collection of nonintersecting polyhedra. They're also tedious to texture so maybe it would be better to do that in a more professional environment.

  6. #66
    Guess there's not a lot of interest in something that's still so primitive

  7. #67
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    Hehe I seem to remember saying something just like that myself (post #2 on pg 1).

    I just think folks have been saturated with "ZOMG 3D!!" posts over the last year to two years, it's tougher to make an impact on the audience with so many high quality examples already out there. Content is king - and I got nuthin there.

    EDIT: The roller coaster will continue - I don't think flash_gamer meant any harm - he's right, there's _plenty_ left to do. Render I will post some guidelines for making enemies later today. General polygon soup will be hard to digest but if it's already clearly decomposed into polyhedra, like roboman over there, the import is tractable.
    Last edited by rachil0; 08-01-2008 at 09:10 AM.

  8. #68
    FK founder & general loiterer Flashkit's Avatar
    Join Date
    Feb 2000
    Location
    Sydney
    Posts
    1,149
    dont listen. I watch this thread like a hawk, then when I read it I get into a state of significant depression then I get inspired then depressed again.

    So continue to please keep me on this roller coaster!
    Regards Mark Fennell - Flash Kit Founder, general loiterer
    -------------------------------
    I Hate Zombies - iPhone Game | markfennell.com

  9. #69
    Student
    Join Date
    Apr 2001
    Location
    -
    Posts
    4,756
    Quote Originally Posted by rachil0
    I just think folks have been saturated with "ZOMG 3D!!" posts over the last year to two years, it's tougher to make an impact on the audience with so many high quality examples already out there. Content is king - and I got nuthin there.
    I could give you some models or content if you could provide a pipeline that I can work with.

    like for example the enemies,- could you give a example data (string or array/code snippet) of how it is constructed? Because if it were something like vertex points with face definitions I might be able to write a exporter for max.

  10. #70
    Quote Originally Posted by Flashkit
    dont listen. I watch this thread like a hawk, then when I read it I get into a state of significant depression then I get inspired then depressed again.

    So continue to please keep me on this roller coaster!
    ditto... just in awe... don't dare get too close

  11. #71
    Senior Member
    Join Date
    Sep 2006
    Posts
    132
    Guess there's not a lot of interest in something that's still so primitive
    Don't just assume that because I haven't commented much doesn't mean I'm not interested. When I seen that shadows have been added too, I was thinking, wow, how far will this go.
    May 2009 - Working on Thorenzitha RPG - episode 7

  12. #72
    Senior Member
    Join Date
    Sep 2004
    Posts
    633
    Content is king - and I got nuthin there.
    Don't worry. Neither does anybody else.

  13. #73
    Senior Member chriserrorplain's Avatar
    Join Date
    Aug 2002
    Location
    london village
    Posts
    623
    this thread (well the project it is around) has been an utter inspiration, it would be nice to see a playable game utilising the engine, but that would just be a nice to have. This is what coders are supposed to do with their time, break new ground, see if things are possible with technologies, do hard maths for fun

    I would rather read a hundred threads like this, as opposed to see thread after thread of Mochi-filled sub standard games. And Mike, before you say why bother cos Director could make a Descent style game just by importing the mesh straight in, isn't it just cool to see if Flash can do it, not even to deploy it, or sell it, but just to see if the platform and the coder are up to the challenge.

    Crikey...I'm starting to sound like Render, I need to go off and watch 'Wall Street' again to get back to my normal capitalist ways

    Christopherror x

  14. #74
    Student
    Join Date
    Apr 2001
    Location
    -
    Posts
    4,756
    you all have been fooled
    that user "flash_gamer" has been spooking around here lately and posting random quotes almost like a bot just to get attention to his former 5 now 3 links (2 were before in each of his posts) to his flash game- I reported him alrady a few times to the mods because at the beginning it was to obvious and some of his posts got alrey deleted.
    For some reason he was to shy to create a own thread so he replied to others to dumb his links. I bet he hasn´t even read all of this thread so it´s no wonder that when quick thinking on a reply something like that turned out.


    And of course it is not primitive, if I am not mistaken it was rachil0 that pointed out some flaws to and made suggestions to Adobe regarding the new capabilities in FP 10 - and has proven some of us that there are also other attempts in 3d Flash that can be well performing.
    For the sake of flash this thread is of course more interesting (at least to me) compared to many others here- but that´s not because it is 3d but rather because it is different and done in Flash.

  15. #75
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    Sorry for the delay in response, real life stuff took over there for a few days. On the upshot, now it's Dr. rachil0, so that's something

    Here's an outline of how the monsters are built up from a union of nonintersecting, convex polyhedra. The screenshot from post #59 (07-18-2008, 03:34 AM) is a good demonstration - each green square indicates one polyhedron. Dissecting further, polyhedra are just (unordered) collections of polygons, and polygons are ordered sequences of vertices. Vertices wind counterclockwise to define the normal of the polygon, polygons are 1-sided.

    I don't mind getting polygon soup. As long as it's pretty clear, by inspection, how the polygons should be collected together to make polyhedra. I think models should be <100 polygons total. That's why I think robots will work so effectively - you expect them to look like they're built out of blocks and pin joints.

    Geometrically, the trickiest part is that you can't just throw a hodgepodge of polyhedra together and expect them to z-sort correctly. They have to be partitioned into a bsp, preferably without splitting any polygons. The bsp is constructed by the map editor program, by testing each polygon in the model as a partitioning plane. When a plane is discovered that doesn't split any polygons*, the model is broken into two (hopefully equal) halves, and the partitioning recurses on the halves/submodels. The tail case of the recursion is a single convex polyhedron, which doesn't need to be split any further because it cannot self-occlude. [*If no such plane is found, the bsp process gives up. At that point it's up to the user to split the model by hand along some cutting plane, and try it again. Try to avoid this case, it will cause a dramatic increase in the size of the input to the renderer]

    Here's how this partitioning works on a 2D roboman:



    This bsp business limits your geometric flexibility. As a monster designer, you should have a good idea of how this bsp process will carve up your model as you're working. Try to make your model such that exactly one partition plane will be found for every subtree, just to avoid unpleasant surprises at runtime (extremely unbalanced trees).

    As far as texturing goes, that's a whole other mess. I think that UV pairs are typically defined per-vertex in a modeling program, but this engine stores a complete UV coordinate system on a per-polygon basis. I think it's best that you not bother with trying to import the UV coordinates into the engine, just supply the geometry and the skin (like your color-cure examples) and I can fix it up on my end.

    I'd really love to get a skin for roboman - maybe covered with a flames/teeth like a ww2 fighter plane, or a steampunk design with big gearwheels on the joints and brass/chrome fittings. Or camoflage I have no painting/texturing ability whatsoever - that's the #1 aspect that I would like to outsource to a more talented artist. I feel pretty comfortable with making geometry.

    There's a link to roboman's geometry in this thread, it's just an xml file:
    http://board.flashkit.com/board/showthread.php?t=773035

  16. #76
    Now tell me whos watchin...... samvillian's Avatar
    Join Date
    Feb 2007
    Location
    Where do you live?
    Posts
    539
    its looking great. Really a great inspiration. Makes me wanna quit flash because i know i wont get to that level lol. So you're a doctor now? dont know if that was a joke or not but you stated you were graduating soon so idk. If so, what kind?
    If the only tool you have is a hammer, you tend to see every problem as a nail.

    Xbox 360 Modding Controller PS3 Mod Paint Spray LED Case

  17. #77
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    Some updates today:

    Support for skyboxes. They are the same data structure as regular maps, but are made of just a single cube. They are textured into the monster layer as a first rendering pass, while the monster zbuffer is filled with z_infinity-1. As the regular map is rendered, any polygon tagged as skybox will draw no texture and write a polygon into the map zbuffer with z_infinity. When the two layers (map & monster) are z-composited, the skybox pixels will be exposed just like regular monster pixels. I can't take credit for the nice skybox texture, it is a "lunar landscape" by Hazel Whorley. He's got a pretty cool site, http://www.hazelwhorley.com/skyboxtex2.html, with lots of FPS game assets available under creative commons. Here's a screenie:



    Support for laser beams - hitscan weapons that leave a tracer line when they are fired (like doom-a-like). These have their own sorting issues. They are cast across cells, splitting across every portal until they hit something solid. Inside each cell, the beam is sorted against the brushes/pillars by splitting into fragments using the local bsp. Beams are drawn into the map layer, so they zort against monsters (and the skybox) by z-composition. Another screenie, showing all this sorting. (The beam is occluded correctly by the pillar using the bsp, and the monster leg by a z-test, just testing different code paths).



    Right now the beams persist forever, so you can fire one and then view it from other angles to test out the sorting. If you look close, they're actually texture mapped across their cross section I flat shaded them at first but they looked too harsh when they were up close. The beams do not z-sort against each other. I will _not_ be fixing this, it's not worth the effort and won't be noticeable when beams are only 1 frame in duration)

    More odds & ends:

    Surfaces are shadowed lazily / on-demand, and released using bitmapData.dispose() if you don't look at them for a while. I hope this will curb memory usage somewhat as maps start to get larger in size. There is now a noticeable frame rate hit when you spin up a room and all the surfaces are filled at once. I might try to spread that out across frames but probably just leave it as is. You can test this feature, if you walk right up to a single wall and just stare at it, memory usage should drop sharply after about 15 seconds as all the other walls are purged due to inactivity.

    Bulletholes are placed on surfaces when you shoot them with lasers. Currently, you'll also mark up the skybox when you shoot (whoops!). This will be fixed later when the player's avatar is eventually refactored into a distinct class from the camera. Hit CTRL to shoot.

    Z-Buffer depth was increased to 768 colors instead of 256. Still not happy with the z-buffer implementation. GradientFill still sucks.

    Here's a playable demo. It's 2.1 MB now because of the skybox textures.

    http://esl.eng.ohio-state.edu/~rac/quake/skyboxdemo.zip

    Quote Originally Posted by samvillian
    Really a great inspiration.So you're a doctor now? What kind?
    Thank you for the positive feedback. Yep! Not really a "turn your head and cough" doc, but a Ph.D. in electrical engineering. No more school Bout damn time.

    EDIT: Fixed broken link to demo.
    Last edited by rachil0; 08-13-2008 at 01:55 AM.

  18. #78
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    Not as much time to work on this as I would like, so just a minor update today. Implemented doors. They are solid polyhedra that translate about in and out of view, like the doors in doom/quake. I might also implement descent-style doors, which are basically animated paintings with transparent pixels (It is easier to make artwork for these, but IMO they don't look as good).

    The engine does exploit occlusion by closed doors. When a door opens/closes, it toggles a flag on the containing sector. When set, this flag prevents the renderer from recursing through to deeper sectors.

    Only stills today, no playable demo. You'll just have to imagine the door in motion. Here's some examples, I plan to make some more designs that use original artwork.

    This is a doom style door that goes straight up into the ceiling.



    This is like a double pocket door that hides in the walls to both sides.



    This door is made up of four triangular panels, that sweep out like an iris. The design and texture are jacked directly from descent, but here it really is a 3D geometry with some thickness on each panel. This one looks especially neat in motion.



    Still grinding it out, one feature at a time.

  19. #79
    Script kiddie VENGEANCE MX's Avatar
    Join Date
    Jun 2004
    Location
    England
    Posts
    2,590
    Nice! And great job on becoming a doctor.

    Is it a problem that I can't see lasers when I fire them (but the bullet hole does appear)? That is to say, I have to strafe to one side if I want to be able to see it.
    http://www.birchlabs.co.uk/
    You know you want to.

  20. #80
    Student
    Join Date
    Apr 2001
    Location
    -
    Posts
    4,756
    hr hr ^^

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  




Click Here to Expand Forum to Full Width

HTML5 Development Center