[F8] 3D Engine material implementation

[Pazil]

Hey.

Before posting any official post about my 3d engine (nothing secret, for everyone to use!), I just wanted to sort out a few problems I'm having.

The problem is that I want to use materials in my engine, so that the way any particular face shows up on screen is very easily interchangeable, but I have no idea on how to do it! I mean, I do have some ideas, which are the following:

-Renderer renders the points, and then the actual drawing on screen process is handed over to the face's material
-Renderer renders the points, and then the face's info is handed to the material, and then the material uses that info to return either a colour or a bitmapData object, with which the Renderer draws on the screen.

I'm pretty sure that the second one would run faster, but since the 3d engines out there are pretty damn interlinked (it's hard to find what you're looking for), I don't know what they use, and therefore I'm not sure which way to go.

I really hope someone will have at least a few ideas on it. This seems to be the only problem facing me before I'll feel comfortable with uploading my engine's class files and everything for you guys...

Also, if you don't have any ideas, you can also help out by telling me about your expectations from a 3d engine, like priorities (speed over good texture mapping, usability over optimized data organizing and vice versa etc.).


P.

[MikeMD]

Able to run ridge racer, wipeout or sega rally at at least 30 fps with at least same level of detail seen in sega rally.

[andreaskrenmair]

I don´t know how your engine is structured, but I would store the vertices and the material in one class. You could start with a super class Face and create subclasseses (BitmapDataFace, ColorFace, ...). So you can create a specific class for every material you want to use.

[Pazil]

That sounds like a good idea! I'm probably now going to make the material class not a class, but simply a property of the face class, which will have colour, and bitmap properties!

Thank you! You really did help me think of new ideas today! Today is the birthday of Latvia! Actualy no, it's no tuesdaya! but today we celevrate cause it's weekend!

[rachil0]

I think a good way to map this concept to code is have all materials either inheirit from a common base class or implement a common interface. Quake-a-like uses this kind of polymorphism - polygons hold references to an AbtractTexture. has a pure virtual function, "render(g : Graphics) : void", which is a hook for textures to draw themselves into a supplied graphics context. Subclasses of texture (like BitmapTexture, AnimatedTexture, ShadowedTexture, etc) inheirit from AbstractTexture and can override this method with more specific drawing routines.

[andreaskrenmair]

That sounds like a good idea! I'm probably now going to make the material class not a class, but simply a property of the face class, which will have colour, and bitmap properties!

Thank you! You really did help me think of new ideas today! Today is the birthday of Latvia! Actualy no, it's no tuesdaya! but today we celevrate cause it's weekend!

np, but you should really consider what rachil has proposed above. That´s a really clever way.

[Pazil]

That is also one of the things I originally had, a base Material class, which has ColourRender(colour:Number) and BitmapRender(bitmap:BitmapData). Then, the extended bitmapMaterial or whatever render function just munches over the bitmap/colour, and then passes it into one of the 2 super class functions.

Even though this may be what the other engines do, I was thinking about how to optimize, and including the bare necessities a good, flash 3d game should have, which means colour and bitmap textured faces, basic lighting / shading, and of course, depth sorting, and basic hittest functions / physics. This means, that to make it as fast as possible, we should just squish everything into the main render class. Since we'd be only dealing with either colour or bitmap faces + the lighting on them could be done by the lights and specific properties of the face, it would still be readable enough, and this would optimize it by a LOT, since there's no jumping from class to class looking for functions etc., which, if you need to do that for every single face in a 3d engine, is achingly slow.

I'm still deciding whether to weigh speed more than usability/easy-to-usiness, but I think that most people would like the speed from it, since there's no point in having something easy to use, if it doesn't run fast...

What do you guys think? Speed or usability.


P.

ps: an idea I had about the bitmap texturing...I noticed that the engine of renderhjs takes the whole texture image for every face, and then moves it etc. in the right position. I was thinking that before the engine starts rendering even, the bitmap material class would take the texture image, and according to the uv points, it would clip the image so Flash doesn't need to take all the pixels of the image, and only transforms the needed ones...?

[mr_malee]

both.

I don't want to look through your API at all when developing. Give me enough options to customize what I want and you deal with processing those options. I think moving processor heavy code into your main render function is a good idea.

as to your last question. What If I wanted to change the texture or do stuff to it?

[Pazil]

about textures: I think that the way you would define if you want to do that clipping, then you just specify a static property when you declare the face, and most people understand the static means no moving or anything. If you really need to move around the texture or something, then you just don't specify the static property...

I understand that looking through the 3d engine's api is not on everyone's to do list, but lots of people want to learn from the engines. Then again, I can just comment like crazy, and also type up a nice, long, text about the engine, it's background, theory, etc.
I'm also not sure if I want to include data management classes (meshes, etc.), since I want to keep my engine as low grade as possible (meaning I don't want a big separation between standard development and the core of my engine, it would act more like an add-on). I mean, would it be that hard for developers to create their own arrays and stuff to organize their objects? Then again, it might be better to include the data management classes, since then it simplifies actions like translating in 3d, and also rotation.

I don't know how much of all that would affect the renderer's speed, so I want to hear some suggestions maybe? This whole time I'm refining my engine, and simplifying things, and optimizing, so hopefully you guys will have a visual example to think about soon!

P.

[renderhjs]

a few slightly offtopic things (sorry about that )

a micro engine would be nice,- not like the many other bloated ones. Make it accessable to the ones that are capeable of good till advanced Actionscript so that they can toy around.
Tiny filesizes would make it as attractive as those tweener classes- easy to include (the more complex the engine,- the more classes to be attached) , smal size ,...

not excatly the same but at polycount:
http://boards.polycount.net/showthread.php?t=55485
another guy wanted to develop a 3d viewer (based on PV). My main suggestion like in most cases then (including you) is to simplify matters for the designers to get their models and textures without much hassle in the engine.
like the idea of sophie3d:
http://www.sophie3d.com/website/inde...?page=p3hdh0ml
where the devloper used the Flash player 10 capabilities to write custom binary data (can be text based or images as well) on the users desktop.
That way one could even generate custom file formats (like sophie3d does),- hell you could even generate your personal engine classes that way- no need for php ect.

maybe set some target goals,- like what makes out your engine - is it really fast, does it have more feautes, is it easy to use for others, smal filesize,...

found today another engine,- from a chinese guy
http://newx3d.cn/
http://www.newx3d.cn/texture/main.swf
interesting stuff can be seen here:
http://newx3d.cn/blog/?p=54
gonna ask a friend tommorow to translate some of it for me


about your initial problem regarding which route to go:
just pick one,- one cant do everything right at the beginning,- maybe it was the wrong route in the end- or maybe a 3rd would be the best solution but you will most likely find out for sure if you go any direction for now.

I learned that alot myself in Actionscript development, because I couldn't understand others engines (java, c++, flash,...) I had to find out and learn most of it myself often resulting into very differrent directions sometimes beeing worse but somtimes also more unique. That's the advantage of beeing unsure of things,- not knowing yet everything- in the end you might end up with something different as others.
But with all you have thought of so far,- keep in mind that dynamic textures (e.g animation, scrolling,...) might be a interesting feature to keep as it could make things way more interesting compared to many other API's.

[mr_malee]

the biggest optimization you could do is moving it to AS3. Plain and simple.

Process heavy code in bulk, avoid calling many functions, store references outside of loops, don't create new objects (point, object, array, matrix) try to use only one.

Imo, data management should be part of the engine and be transparent for the developer. Stuff like adding objects, managing what needs to be drawn, lists of children, spacial queries, all that stuff should be part of the engine.

[Pazil]

I understand about the data management, and of course the lists of objects to render would be managed by the engine, but I was refering to moving a lot of vertices at once (myObject.x ++) or something. I don't think it's a big deal, and now that I think of it, I will keep it inside my engine.

The way I see things, speed is the most important any 3d engine in Flash (and else where for that matter) has to have. What point is effects if you can't perform them real-time, and with considerable effectiveness?
Building on that, I don't want to leave developers in a maze of code, variables, objects, etc., which means I'll have plenty of documenting and explaining to do afterwards, and I'm not too interested in legibility of code right now.
(I'm keeping in mind to try to recycle arrays, objects, etc., plus would deleting variables after I'm done increase speed?)

AS3.0 is a thing that will definitely come as soon as I get Flash CS4. I'm working with plain old F8 right now...

render, that seems like an interesting new engine, except a) I can't read it at all! ha, and b) it looks like all the other engines...then again, it's more of the core that matters, and how they got it showing what it shows...
It would be good to see more of that soon!

Tweener classes are now on my checklist (I hadn't thought of them before). I'm going to do a sketch up of my engine pipeline soon, and see what you guys think of it! So far I have the ideas sorted out in my head a bit more, and just need to get it into the computer.

Also working on importers.
Hell, I'm working on everything right now!

By the way, do you guys think people most likely like to work with professional modeling interfaces, or would a nice, home made, flash modeler be good to download with the 3d engine classes to get set right away?
(I was thinking to have importers for blender files, since Blender is a free, professional program (blender.org).


P.

[renderhjs]

What point is effects if you can't perform them real-time, and with considerable effectiveness?

maybe you have some special effects like normal mapping, glowing materials, or other stuff that eats up the performance. In that case just use less triangles and you are done. Just a matter of perspective.

(I was thinking to have importers for blender files, since Blender is a free, professional program (blender.org).

better dont, there is still a majority that propably uses other tools. Instead try to focus on export formats that are often used like OBJ for example (plain text format btw.).
Ist used as export format number 1 between zbrush, Max, Maya, XSI, Blender, Cinema, Lightwave... because it supports Polygons (e.g quads) instead of just triangles. But it can also export triangles and material definitions.

A future format is FBX (pushed by autodesk that now owns 3smax, maya and XSI)- but its not yet present it older versions of max and maya,- neither do I believe its in Blender yet.

Another shot could be DAE (collada or better known as the playstation 3 format). Its available for most tools and used by most flash engines. Cons:
Bloated filesize

[Pazil]

With the Blender version I currently have, their seems to be a problem with exporting to collada format, but I'll have to try and download the newest Blender.

I most certainly don't have those effects yet, and might not ever have them, but yes, you do have a point. Then again, sometimes the mesh detail is important, like for main characters and such.

Tonight's my scheduled "Engine Re-make" night, so I'm going to be working my ass off for the next while, and hopefully get to show something by the end of it...

P.