Author Topic: Freebasic 3d renderer using tinyptc (Read 26539 times)

Stonemonkey · « **Reply #40 on:** May 23, 2006 »

thanks, no idea what ive done that would make it go from 2 up to 10 tho

Optimus · « **Reply #41 on:** May 24, 2006 »

ABSOLUTELY AMAZING!!!
Never seen such a good 3d engine for freebasic before. Gotta love the commands and stuff, interesting..
27 fps here.

Shockwave · « **Reply #42 on:** May 27, 2006 »

If I know Stonemonkey, it will get much much better.

Any chance of getting this to the stage where the running man demo could be replecated SM?
I'd love to see that running at some silly speed in 640X480 mode.

Stonemonkey · « **Reply #43 on:** May 27, 2006 »

Sorry, not for a while shockwave. little example of something i did a while ago though with some similar effects going on here though.

Shockwave · « **Reply #44 on:** May 27, 2006 »

Jeepers, that's stunning.
Unbelievably quick frame rate too.

Rbz · « **Reply #45 on:** May 27, 2006 »

@Stonemonkey: That demo3.zip It's fantastic !

I just can't believe that this one was software rendered, welldone !

Ghost^BHT · « **Reply #46 on:** May 27, 2006 »

Very cool indeed

taj · « **Reply #47 on:** November 12, 2006 »

Wow, please please please tell me how you were doing the transparency in this demo...can I bribe you with Karma???

Shockwave · « **Reply #48 on:** November 12, 2006 »

I think that he might have resorted to inline asm for a lot of the transparency stuff, Stonemonkey can verify that though.. Stonemonkey also made this nice little definition that makes quite fast alpha blending possible;

Code: [Select]

#define alpha(s,d) ((((s and &hff00ff)*(s shr 24)+(d and &hff00ff)*(256-(s shr 24)))and &hff00ff00)or(((s and &hff00)*(s shr 24)+(d and &hff00)*(256-(s shr 24)))and &hff0000))shr 8

rdc · « **Reply #49 on:** November 12, 2006 »

Heh. I didn't see this before. Looks like the alpha stuff has already been covered. Impressive work on this Stonemonkey.

Stonemonkey · « **Reply #50 on:** November 12, 2006 »

Yep, using inline asm but really just using the same method as in the definition Shockwave's posted there where the red and blue channels are dealt with together.

taj · « **Reply #51 on:** November 12, 2006 »

But it looked like there was some refraction going on...did I see it wrong?

Stonemonkey · « **Reply #52 on:** November 12, 2006 »

Ah right, sorry I forgot about that. It's done by wrapping a texture around the object and then for every frame it first renders to that texture using a camera placed inside the object. Other ways it could be done are with cube or sphere mapping using pre rendered textures although that wouldn't allow for moving objects around so well.

Shockwave · « **Reply #53 on:** November 12, 2006 »

Been thinking about multitexturing.
Tell me if you think this would work..

Render a shadow map from the view of the light source to a texture.

Then multi texture the shadow map over the scene and render the scene from the camera's point of view.

I think that this could work quite well for shadows....

Stonemonkey · « **Reply #54 on:** November 12, 2006 »

That's a method that's sometimes used but i've not looked into it in much depth as i think, particularly with sw rendering it would suffer quite badly from visible stepping of the shadows. I think it can be done well in hw but i'm not sure how.

Shockwave · « **Reply #55 on:** November 12, 2006 »

There's nothing new under the sun eh?

There was me thinking I had had a brainwave!

Stonemonkey · « **Reply #56 on:** November 12, 2006 »

heh, that's happened to me a few times too but i think it's pretty cool when it does as it shows you're thinking along the right lines.

http://en.wikipedia.org/wiki/Shadow_mapping

taj · « **Reply #57 on:** November 12, 2006 »

Quote from: Shockwave on November 12, 2006

Been thinking about multitexturing.
Tell me if you think this would work..

Render a shadow map from the view of the light source to a texture.

Then multi texture the shadow map over the scene and render the scene from the camera's point of view.

I think that this could work quite well for shadows....

Well it always helps to deduc things yourself from first principles. Its a technique used in OpenGL. Here is a cool article on the maths

http://www.paulsprojects.net/tutorials/smt/smt.html

Shockwave · « **Reply #58 on:** November 13, 2006 »

Cheers Taj.

The reason the thought of doing it like this came to me wasa that I was thinking about Stonemonkeys SW engine and the way he does the shadows, he explained about the principles of having a prism like volume and everything contained in it's projection being in shadow..

I was thinking about casting shadows onto objects which are cones, spheres etc and just thought why not render the shadow and texture map it onto the object.
Shadows aren't something I can say I've ever really done, I'll most certainly be trying this technique out when I can get some stuff happening in CPP.

taj · « **Reply #59 on:** November 13, 2006 »

Quote from: Stonemonkey on November 12, 2006

Ah right, sorry I forgot about that. It's done by wrapping a texture around the object and then for every frame it first renders to that texture using a camera placed inside the object. Other ways it could be done are with cube or sphere mapping using pre rendered textures although that wouldn't allow for moving objects around so well.

Mr Monkey,

Stone, I dont quite get it. Could you be a bit more precise. I'm asking because the code to do refractions in OGL (using cubemaps) requires extensions ansd is therefore expensive in 4k. However you seem to be using 1 texture per object. The technique might be very useful, could you maybe detail it a bit more? I get rendering from inside the object, but how do you decide but how did you decide what the texture co-ordinates are on the object? What field of view do you use for rendering the view? Does it change depeding on how far away the object is or not? Any hints and tips could earn a stone banana...