Hello everyone! 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

https://github.com/Zaalan3/quad3D

Wow, that's looking really cool! I can't wait to see how it turns out!

Nice to see you've got it running - can't wait to see how it will evolve

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

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

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 !

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!

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

where

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!

https://github.com/Zaalan3/quad3D

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.

Marvelous

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.

A number of updates this time

Rewrote the face caching code into assembly. The current benchmarks are:
~2000 cycles per vertex
~2800 cycles to process a front facing polygon(700 for offscreen and 1500 for backfacing)

Added some basic mipmapping(polygons with a small area use the 16x16 shader). Still not sure if a 64x64 version is necessary or not.

Implemented the SHA256 stuff. Basically just a few minor changes to theMachine02's version of that code so that it plays well with C.

And a few other other minor changes

Next steps:
▪ Add a sprite system. Transparency is already implemented so I think I'll use the same shaders I've been using for visual consistency. Shouldn't be too hard to simply change a few bytes using SMC in the projection code to handle normal vertices and sprite positions.
▪Add a lighting system. I'm thinking by again just reusing the matrix code I have I could relight a face at around ~600 cycles each. Face normals will just be another list of vertices that get passed to the vertex transform function. I need to get off my butt and make a palette before I start implementing this though.

Finally I need to need to make an obj->c file util. Probably just going to be a fast and ugly java file. Maybe I'll learn some python and make a blender export plugin eventually.

That's very nice

What does the engine give with a few more polygons than a cube ?

Also, for the sample issue, could you roughtly scale the sample (giving a rect with a fixed dx and dy dimension for the whole quads) to fill in the gap and lessen the error ? The other solution would be a 64x64 and a 128x128 sampler, but that should be harder - however I think you could sample at lesser texture resolution and duplicate the result.

Just a question: Are the movements of the cube in the first demo screenshots random generated?

No, just Euler angles have different initial values, that increment on a perframe basic.

As for the scaling issue, I'm not quite sure how well that would work(outside of having a mipmap style prescaling). Maybe dynamic subdivision of large polygons? Simply needs more testing to be done at the moment.

Getting started on my obj converter Should be ready some time soon.

Sidenote: vertex early exit gets ~600 cycles for out of range z and ~1400 for x out-of-bounds at the moment.

Model converter is working!
Here's an untextured suzanne
499 faces
507 vertices
~5,500,000 cycles to render (around 7 frames or 8 fps)

Great work! . Is it possible to increase fps, if so how?

That's some nice looking screen right there !

My renderer doesn't push much more frame on suzan than that (altough I never really got around implementing quad rendering, 967 faces is quite a hit !), so I can't wait to see where this will go

Well, the simplest way would be to better optimize the model. There's a lot of faces that could be combined/dissolved to improve performance. Besides that, I would say the engine is unoptimized right now, so performance will improve in later versions(for example, by seperating the transparency code into it's own shader, it takes about 300,000 less cycles to render this model).

Thanks for your kind words

Zelda model with that stone texture I always use

824 vertices, 349 faces.