Programming C, C++, Java, PHP, Ruby, Turing, VB
Computer Science Canada 
Programming C, C++, Java, PHP, Ruby, Turing, VB  

Username:   Password: 
 Different approach to 3d (I think)
Index -> Programming, Turing -> Turing Help
Goto page 1, 2  Next
View previous topic Printable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic
Author Message

PostPosted: Sat May 15, 2004 2:08 pm   Post subject: 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?

PostPosted: Sat May 15, 2004 3:06 pm   Post subject: (No subject)

nice job Very Happy

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?

PostPosted: Sat May 15, 2004 3:48 pm   Post subject: (No subject)

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.)?

PostPosted: Sat May 15, 2004 6:05 pm   Post subject: (No subject)

i think my head just exploded...
Do you have some sample images or something that will explain your method visually?

PostPosted: Sat May 15, 2004 9:27 pm   Post subject: (No subject)

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...

PostPosted: Sun May 16, 2004 3:10 am   Post subject: (No subject)

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)

PostPosted: Sun May 16, 2004 1:47 pm   Post subject: (No subject)

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...

PostPosted: Sun May 16, 2004 2:00 pm   Post subject: (No subject)

Its that fast because turings built in draw functions are actually written in another (much faster, i beleve they use c++) language

PostPosted: Fri Aug 20, 2004 8:57 am   Post subject: (No subject)

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?


PostPosted: Fri Aug 20, 2004 11:14 am   Post subject: (No subject)

I suppose one would read all they can about the topic. Very Happy

PostPosted: Fri Aug 20, 2004 1:27 pm   Post subject: (No subject)

hey mazer.. what language was that routin (in that link) nmade outa ?

it was like turing.. but not quite..

me liked..

PostPosted: Sun Aug 22, 2004 12:00 am   Post subject: (No subject)

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)

PostPosted: Sun Aug 22, 2004 7:43 am   Post subject: (No subject)

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.

PostPosted: Sun Aug 22, 2004 4:12 pm   Post subject: (No subject)

as I thought, it just looks like turing cause turing is made to make it easy to learn Razz

PostPosted: Mon Aug 23, 2004 11:25 am   Post subject: (No subject)

yea... turing loooks like pwuedo code..

are there any other lanuages that look like it kinda?
Display posts from previous:   
   Index -> Programming, Turing -> Turing Help
View previous topic Tell A FriendPrintable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic

Page 1 of 2  [ 16 Posts ]
Goto page 1, 2  Next
Jump to: