Hello everyone! Smile I've reached the first stages of the creation my 3d engine. Right now, it allows for arbitrary rotation of 'objects' and a free moving camera. Very unoptimized, I didn't want to put the chicken before the egg.

Interestingly enough, I've been messing about and implemented a form of forward mapping: using bilinear interpolation to directly map a texture to a quad. This allows for some interesting effects, but leaves artifacts in the form of holes where pixels aren't directly mapped. It uses 32x32 textures, but I'm planning on implementing a 16x16 version(since rendering cost scales with texture size, not polygon size, making it great for mipmapping).

The only real problem with this method is that clipping is quite different than for a standard polygon. I think it would be best to simply change to the 16x16 version, than perform a per texel test to see if its offscreen. Here are the projected cycle times:

32x32 unclipped : 50,000 cycles per quad
16x16 unclipped : 13,000 cycles per quad
16x16 clipped : 25,000 cycles per quad

Wow, that's looking really cool! I can't wait to see how it turns out! Very Happy
Nice to see you've got it running - can't wait to see how it will evolve Smile

About your forward mapper, do you feel it is more efficient than standard inverse mapping ? What kind of compute per pixel do you have ? Smile
Thank you!

The forward mapping is generally more efficient than two triangles (for a polygon around the size of the texture). For the unclipped version I'm currently using its about 42.75 cycles per texel(that plus overhead leads to about 50000 cycles), with two triangles of approximately the same size probably being around the 80k to 100k cycle range.

Some of the effects I think could be achieved through clever usage are semitransparenct(abusing the fact that the forward mapping leaves holes) and curved surfaces (caused by the quadratic nature of the mapping for nonplanar polygons). I'm kind of cribbing these ideas from some video systems that used similar effects, notably the Sega Saturn(and by extension the Nvidia NV1) and 3DO Smile
Well - I've read about NV1 chip and 3DO rendering, and it sure looks interesting, I am still quite puzzled by the computation involved in the mapping.
Sphere rendering using 8 quads seems indeed fun, altough that mathematically induce quite a burden on model design.

~42 cycles per texel seems good (I guess SHA ins't used yet), altough I fail to see how a "big" quads will be mapped - will it be with many holes ?

Can't wait to see those pieces of code ! Smile
Looks awesome and is running well!

I can sort of see some of the gaps, what does it look like with a large quad or if it's closer to the viewport?
The gaps you're seeing are directly related to quad size - the larger the difference between the texture size and the quad the larger the holes will become. Do note that if the quad is smaller than the texture than the holes will decrease. This mapping system works very well with spaces with plenty of subvided polygons, but with big polygons, it would lead to that semitransparency I was talking about before.

I'd actually never thought using the SHA space for a small routine, but now you've got it stuck in my head! Surprised

The basic formula this routine is based around is this special case of bilinear interpolation for a square:
(x,y) = Auv + Bu + Cv + D


A = p0 - p1 - p3 + p2
B = p1 - p0
C = p3 - p0
D = p0

Fixed render time since its tied to texture size, but visual problems for large polygons:

I like that since there doesn't appear to be the kind of distortion that affine mapping produces re inverse mapping.

OK I see how it's fixed render time since it's basically the same number of pixels with gaps if larger than the texture.

Do you have any ideas on closing the gaps though?
I suppose you could either up the sample count for large quads or up the pixel size rendered, altough that won't scale very well in term of render time.
Update! My code is finally it okayish condition! Razz


As for the large polygon problem, I think more samples is the way to go. I've tried big pixels before and they don't look good and don't scale well.

Sidenote, can y'all show me how to go about unlocking the SHA256? I've never touched the port or flash unlock stuff before. Smile

Marvelous Smile

For SHA256, you need to unlock protected port (bit 2 of port 6) (cf wikiti and cesium source code) to be able to read/write to the SHA register. Do note that the boot code interrupt handler does reset this bit each time it runs, so you have to disable interrupt globally if you want to use the fast area.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum