----------------------------------- Ultimus Sat May 15, 2004 2:08 pm Different approach to 3d (I think) ----------------------------------- I've recently stated work on a 3D modelling engine that I think runs very fast (at least compared to the others I've seen here). This is my first attempt at 3D modelling (and I thought this up without reading any tutorials), so my approach is probably far removed from conventional ones but here's basically how it works. If you know anything about 3D rendering, I welcome you to comment on/suggest improvements for its practicality... The engine uses standard internal srawing procedures and is plane based; you call a procedure and pass the engine 3 points (each having x,y,z coords) and a color. This information is tucked away into memory and you may add as many of these points as you wish (providing you have the ram, although on today's systems that shouldn't be an issue). You then call another procedure to set up the camera position, focus, and FOV. When you are done, you call a rendering procedure, which begins the drawing of the polygons. Now, for each set of data, the three points are seperately translated according to the camera settings, so that they are moved to new strandard positions, having compensated for offsets due to camera position. Now, the sets of points are arranged into drawing order, with the furthest points to be drawn first. Them, we start a loop, and the z coords for each point are processed into the x and y coords, resulting in a virtual 2d plot of the 3d coords. Then, a seperate, invisible buffering window of equal size to the main i/o window is created, and 3 lines are drawn between the points to form a triangle, and are then filled with the color specified, thus forming a plane. This image is then copied out of the invisible window and drawn into the main one. This process repeats for all planes, and because they were previously arranged by layer, the upfront planes overlap the ones in the background. I have also included a (highly buggy) algorithm to determine if planes in the background are hidden by foreground planes in order to save cpu time by not rendering planes that will be overlapped later anyways. Once all of the planes are drawn, the image in the main window is updated and voila! The final render. BTW, on my machine (2.66 Ghz P4), I can typically draw 5000-5100 planes per second (330+ max planes per frame at a satisfactory 15 fps. Currently I am attempting to add low quality lighting effects/textures to the planes... but it just presents more problems, it seems, and turns the engine more into a snail like the others I've seen... Now, if you haven't died of boredom or mental overload, can anyone help suggest what I should improve here? Could this engine be useable for realtime games like shooters? ----------------------------------- Catalyst Sat May 15, 2004 3:06 pm ----------------------------------- nice job :D 330 triangles at 15 fps is about what the other 3D engines here get (actually a bit less) by drawing to an 'invisible window' do you mean the back-buffer or are you actually trying to exploit turing's faster rendering on hidden windows? ----------------------------------- Ultimus Sat May 15, 2004 3:48 pm ----------------------------------- Regarding that, yeah, I'm trying to get a speed boost by only committing the image to the output window once - when it's fully done. In my experiments doing that was a lot faster than adding each polygon seperately to the out window (and I've found that despite what the documentation led me to believe, the "offscreenonly" setting does NOT make drawing much faster at all, though drawing to "invisible" windows actually does give a very significant 1.7X speed boost - for me anyways - and that saves a lot of cpu time when drawing 5000 times per second). Anyways, exdanding on what I said earlier... how does this method of rendering compare to others. I have no knowledge of rendering methods and came up with it myself. Has this method already been established and given a definite name (raycasting, etc.)? ----------------------------------- omni Sat May 15, 2004 6:05 pm ----------------------------------- i think my head just exploded... Do you have some sample images or something that will explain your method visually? ----------------------------------- Ultimus Sat May 15, 2004 9:27 pm ----------------------------------- Wohoo! Update on the speed report. I found some unnessecarily continued loops and terminated them early... and I'm up to a personal record of 6782 triangles in one second = 452+ tpf @ 15 fps. I'll look at other shortcuts I can take to speed this baby up some more and then I'll prolly release the source... ----------------------------------- Catalyst Sun May 16, 2004 3:10 am ----------------------------------- how are you drawing ur triangles? Im asking since u seem to be putting a lot of effort into speeding it up (invisible windows and such) when drawfillpolygon can render 200-300 triangles in 8-10ms (the bottleneck for my engine is the sorting and lighting calcs) ----------------------------------- Ultimus Sun May 16, 2004 1:47 pm ----------------------------------- Really? Wow, I never thought using drawfillpolygon would be THAT fast. Currtently I use drawline X3, then drawfill. What really kills it though is the drawfills... They're so slow (compared to drawlines)! But thanks for telling me about this. If drawfillpolygon really is that fast... ----------------------------------- Catalyst Sun May 16, 2004 2:00 pm ----------------------------------- Its that fast because turings built in draw functions are actually written in another (much faster, i beleve they use c++) language ----------------------------------- TheZsterBunny Fri Aug 20, 2004 8:57 am ----------------------------------- Sorry for bringing up an old post, but theres a nagging issue I need resolved. How does one convert the Z coordinates into the X and Y coords? -Z ----------------------------------- Mazer Fri Aug 20, 2004 11:14 am ----------------------------------- I suppose one would read all they can about the [url=http://www.compsci.ca/v2/viewtopic.php?t=4046]topic. :D ----------------------------------- the_short1 Fri Aug 20, 2004 1:27 pm ----------------------------------- hey mazer.. what language was that routin (in that link) nmade outa ? it was like turing.. but not quite.. me liked.. ----------------------------------- Delta Sun Aug 22, 2004 12:00 am ----------------------------------- ya... well it does look like turing... except the freakin' routine isn't complete... if you are going to make a tutorial on something shit at least complete the tutorial... or give an example source (completed example source)... jeez *shakes head in disappointment) ----------------------------------- Mazer Sun Aug 22, 2004 7:43 am ----------------------------------- Are you people kidding me? Please say yes. Are you familiar with 'psuedocode?' It's not a real language, and that's the whole point. You want to make something 3D in turing? Great, so why should you care about a tutorial written in C++? Or Python, or anything else? Pseudocode is for illustrating coding ideas, not for copy and paste. And if you can't handle that, here you go: procedure draw3D (x, y, z : int) var screenx, screeny : int if z > 0 then screenx := round (x / z + maxx / 2) screeny := round (y / z + maxy / 2) end if drawdot (screenx, screeny, 12) end draw3D That's without things like pan and zoom from the original to simplify it. ----------------------------------- Paul Sun Aug 22, 2004 4:12 pm ----------------------------------- as I thought, it just looks like turing cause turing is made to make it easy to learn :P ----------------------------------- the_short1 Mon Aug 23, 2004 11:25 am ----------------------------------- yea... turing loooks like pwuedo code.. are there any other lanuages that look like it kinda? ----------------------------------- rizzix Tue Aug 31, 2004 9:35 pm ----------------------------------- ALL BASIC like languages look like pseudo code