f3DTo2DF proc uses esi edi X:real4,Y:real4,Z:real4,F:real4,intScreenW:dword,intScreenH:dword
LOCAL xres,yes:dword
shr intScreenW,1
shr intScreenH,1
;X:= ((X/Z) * F) + intScreenW/2
;Y:= ((Y/Z) * F) + intScreenH/2
fld X
fdiv Z
fmul F
fiadd intScreenW
fld Y
fdiv Z
fmul F
fiadd intScreenH
ret
f3DTo2DF endp
About 35 milions fill rate each second. I dont know is it fast enough or not. But on a demo I saw, at least you need 60 millions fill rate each second to gain a good software renderer.
SSE :biggrin:
you could speed that code up a bit by pre-calculating F/Z
;M = F/Z
;x= X*M + intScreenW/2
;x = Y*M + intScreenH/2
it eliminates an FDIV
See if you can replace the fiadds with fadds, it's much faster.
Quote from: dedndave on January 04, 2013, 03:53:41 PM
you could speed that code up a bit by pre-calculating F/Z
;M = F/Z
;x= X*M + intScreenW/2
;x = Y*M + intScreenH/2
it eliminates an FDIV
Yeah, good Idea. I did not even think about that
Quote from: jj2007 on January 04, 2013, 05:13:15 PM
See if you can replace the fiadds with fadds, it's much faster.
Whoa, thanks.
You are wasting your time.
You are never going to plot 3D pixels on screen fast enough by using CPU / FPU or SSE2/4/ whatever.
The correct way to do this is to use the hardware accelerated functions from DirectX or OpenGL
i guess that depends on what you want to do, eh
Quote from: dedndave on January 05, 2013, 01:32:43 AM
i guess that depends on what you want to do, eh
Yes... but however :D
Even for an software render algorithm the most time consuming operation is NOT going to be plotting pixels on screen and the final 3D to 2D transformation.
You will have to calculate the pixel's color first and this is what is going to take a lot of time.
For example going to all the 3D objects lists and intersecting all the rays (assuming raytracer) with all the objects and all the math involved...
Then add reflections, multiple or soft lights, refraction and transparency, add the materials, bumps, displacements and shading algorithms and textures...
My guess is that the final 3D to 2D pixel transformation is not really going to matter at all when comparing with all of the above 3D calculations.
Sigh...
A raytracer would be doing a 2D coordinate to 3D Ray transform, not a 3D coordinate to 2D coordinate transform (aka projection.)
It helps when you don't act like you know what you are talking about when you know that you don't know what you are talking about.
Im impressed with this project http://users.softlab.ntua.gr/~ttsiod/renderer.html it is a pure software rendering. Not so fast on my computers, but it gives freedom for me to do anything what I want.
Quote from: Rockoon on January 05, 2013, 01:03:21 PM
Sigh...
A raytracer would be doing a 2D coordinate to 3D Ray transform, not a 3D coordinate to 2D coordinate transform (aka projection.)
It helps when you don't act like you know what you are talking about when you know that you don't know what you are talking about.
You still need that code to render the basic object. I did not even finished the direction vector for the ray path.
Well, I wont finished it on a year or so. But at least it will satisfied my curiousity. I know how to do raytrace for a simple primitives like globe. It just a simple straigh line trace and wait until it hit the object. Well, I had the tutorial. So I guess I should be fine.
http://www.codermind.com/articles/Raytracer-in-C++-Part-I-First-rays.html
i don't think that remark was aimed at you, farabi - lol
Quote from: Rockoon on January 05, 2013, 01:03:21 PM
Sigh...
A raytracer would be doing a 2D coordinate to 3D Ray transform, not a 3D coordinate to 2D coordinate transform (aka projection.)
It helps when you don't act like you know what you are talking about when you know that you don't know what you are talking about.
Here: http://www.oby.ro/sol_ray/files/sol_ray_2006_07_31_bin.zip
Go get this realtime 3D raytracer written by me at least 6 year ago in ASM using the FPU. I guess this is kind of what Farabi is trying to do.
Try menu option File->Load Texture and then Trace->Start and Animate->Start and then play with the options (shadows, specular, etc)
Then you can select camera or sphere 1 and move them or move around.
PageUp and Page Down moves the camera or selected object on Z axis and arrow keys move on X and Y axis respectively.
Then stop dreaming that I do not know what I am speaking about :bgrin:
In the intro screen of Hostile Encounter game there is a much bigger and nicer version of this used to render the Earth like planet.
Raytracing is a method of rendering a 3D scene on a 2D screen ;)
It has some advantages (shadows, reflections, objects intersections, etc) but it is also very slow when compared to scan-line algorithms that are currently in use in 3D video cards.
If you think a raytracer has to do 3D to 2D projection, then you are truly dreaming.
Raytracers begin with the pixel coordinate. For each pixel... cast ray into scene graph, performing intersection tests, ...
Its rasterizers that need to project from 3D to 2D. For each triangle in view frustum... calculate pixel coordinates of each vertex, then scan down the left and right (or top and bottom) edges...
How do you not know this? Makes us wonder how much of that project is yours.
Just for reference, I was working a software renderer some time back, On my core i7 I was doing 5 million points at 35fps. That was the for the entire pipeline, 4x4 transforms, rotation, treating each point as a vertex and calculating phong shading params at each one, texture look-ups and drawing them to screen just as single pixels. I was using it as a test bench for optimizing my transform stages with simd/swizzles and breaking transformation up into blocks for parallel processing.
In terms of putting together a 3d engine for yourself, I also wouldn't advise doing your projection in this standard equation form. It would be much better to have the whole engine use homogenous 4x4 matrices. That output of a a projection matrix will give you what you need for 3d clipping (homogenous clip space), w coordinate etc. It also makes it easier to scale up to device coordinate space.
Quote from: johnsa on January 07, 2013, 08:25:00 AM
Just for reference, I was working a software renderer some time back, On my core i7 I was doing 5 million points at 35fps. That was the for the entire pipeline, 4x4 transforms, rotation, treating each point as a vertex and calculating phong shading params at each one, texture look-ups and drawing them to screen just as single pixels. I was using it as a test bench for optimizing my transform stages with simd/swizzles and breaking transformation up into blocks for parallel processing.
In terms of putting together a 3d engine for yourself, I also wouldn't advise doing your projection in this standard equation form. It would be much better to have the whole engine use homogenous 4x4 matrices. That output of a a projection matrix will give you what you need for 3d clipping (homogenous clip space), w coordinate etc. It also makes it easier to scale up to device coordinate space.
Thanks for the advice. I appreciate that.
(https://fbcdn-sphotos-a-a.akamaihd.net/hphotos-ak-snc6/321041_4458177212624_203129081_n.jpg)
Raytracing only good for a flat textured image. When the texture image is also shaded, or even worse raytraced. the final result is not really good.
(http://ompldr.org/vZ3c1aQ/RMHWanda.PNG)
I don't see any problem with your textured output there?
It looks like a traditional software texture mapper to me.
Some things to bear in mind however, GPUs are going to be doing a lot of processing to improve the texture quality.. IE:
Bi-linear filtering
Anisotropic filter (in favour of mip maps with tri-linear filtering)
Then of course there is your choice of texture size (the old days it was always 256x256 but I wouldn't use anything less than 512x512 or even 1024x1024).
Shading models will usually include a number of other parameters (good lighting improves texture quality indirectly).
So as a basic you'd want at least full phong. (Modern game engines now also make heavy use of parallax exclusion mapping / bump mapping etc).
There are also many other things to eventually consider, like doing all your shading in a higher bit colour space, so that you can create "HDR" and chop of the overshoot to create post-effects.
my software engine was keeping the color as floats (in theory 1.0 being 255) and any value > 1.0 was chopped off into a seperate buffer.
Yeah, it was not a real time ray tracing, but the texture is a raytraced generated texture map. Bogdan was right doing the intersection on realtime is almost imposible. Using Open Dynamic Engine for calculating a ray only good to 100 ray for achieving 30 FPS. Above 1000, it would be really slow. Some raytracer need at least 100k ray.
I think I better wait until OpenCL is mature.
We're getting to the point where RT ray-tracing is possible even without hardware accel.
Have a look at some of Jaco Bikker's work (http://igad.nhtv.nl/~bikker/). He's using a combination of gpu/cpu to do real time path tracing now.
There are also many good papers by guys like Samuli Laine from Nvidia on some topics.
Quote from: johnsa on January 11, 2013, 05:33:59 AM
We're getting to the point where RT ray-tracing is possible even without hardware accel.
Have a look at some of Jaco Bikker's work (http://igad.nhtv.nl/~bikker/). He's using a combination of gpu/cpu to do real time path tracing now.
There are also many good papers by guys like Samuli Laine from Nvidia on some topics.
Thanks for the link. It is impressive. Also Brigade done a good job on realtime raytracing. But it need a great hardware.