Hi guys,

Just thought id let you know that i have uploaded a project to
ticalc.org today. It is a 3D engine for the TI-83+ series calculators.

The program is a 3D model viewer that enables the user to view and
interact with a 3D model in real-time. Note that it renders
flat pattern-shaded polygons. Also included is a utility to convert
Wavefront OBJ models to .8xp programs for use with this
viewer.

It is written in z80 assembly and a 15MHz calculator is recommended.

Also a note that this is a calculator 3D engine, so please dont expect
performance to be awesome or anything. I dont think you are going to
see Halo on your calculator anytime soon with this engine, its more
just for the novelty of it all .

It is in beta testing so there could be problems. Please report any bugs
if you find any.

Ill update the link when ticalc.org processes it. In the meantime here is a link: http://www.tr1p1ea.net/files/downloads/sfview.zip

Also here are some screenies.




Id appreciate feedback if anyone has some.

Enjoy.

Looking nice !

Also, funny coincidence : I was just about to release my SolidWorks-like program

Mine has on-calc editable models, but is wired, so no surfaces, but it works nice on 6 MHz calcs. I'll post it later anyway

I tested this out a few days ago, before it had the nice UI, and I was quite impressed! I'd love to see some greyscale on it!

did you make the models yourself?

This is beautiful work, tr1p1ea. Are you planning to create an on-calculator editor of any sort, or is that outside the scope of the project. We also would welcome this in the Cemetech archives, should you feel like adding it once a completed version is available. Can you tell us more about the math behind it, especially any sort of tricks or deviations from standard 3D math you had to implement to make things work and/or work at a decent speed?

This looks really nice, tr1p1ea. I like how I can rotate the models relatively quickly, although the screenshots are a little faster than my 84 Plus SE. Do you see this expanding to multiple models at once?

I'm really impressed. Nice work!

It looks quite skilled, good work, tr1p1ea!

Thanks for the kind words . Kerm ill be happy to upload into Cemetech's archives once it reaches an acceptable state .

An on-calc modeller does sound interesting, it will depend on whether i can find the time to try out a few ideas i guess.

flyingfisch: Yeah i made them myself in Blender. I have included a rough utility to convert 3D models in Wavefront OBJ format for use with this project. There are some limitations for models which can be found in the readme. If anyone needs help, feel free to drop me a line. I will probably release a small tutorial on creating a 3D model from scratch and converting it etc.

As far as 3D math goes, well i have a lot of unrolling and taken a lot of shortcuts and such for speed. The model viewed is actually contained within a 16-bit world (a byproduct of my engine testing), which allows the user to zoom in and out by a large margin (im not sure that this is useful). If i rolled it back to an 8-bit world then there may be a speed increase.

One of the tricks i did use during perspective projection is multiplication by a reciprocal to avoid a division. Since the vertex coordinates passed to the projection routines are 16-bits, i have a routine that will scale x/y/z until z is within 8-bits (and subsequently scale x/y by the same factor as well) - for which i use a LUT to grab the appropriate [scaled] reciprocal for (1/z).

The formula i usually use for projection is (there are other formulas for projection mind you):

; x2d = ((x3d * scale) / z3d) + xCentre
; y2d = ((y3d * scale) / z3d) + yCentre

Where 'scale' is around 64 on calc. The division can be expensive so using a reciprocal multiplication instead its works out like:

; x3d * (reciprocal * scale) + xCentre
; y3d * (reciprocal * scale) + yCentre

Where the (reciprocal * scale) is a precalculated value of 1/z*scale for 0-255 and 'scale' takes the need for scaling x3d/y3d as seen in the first formula into account. I use 2048 and then shift the result so as to divide by 32 (2048 / 32 = 64 = scale factor in above formula).

I also have some fast integer math routines so my signed 16bit x 8bit multiplication only takes 368cc's as a worst case. I saved around 2000cc's per vertex using this method.

I also have had a lot of help from qanos, the author of another 3D engine regarding matrix math and especially the use of quternions to store an objects orientation in 3D. Such information has proven very valuable.

I plan on releasing information on how to access the 3D library contained within this project for other programmers.

Excellent, that helps a lot. I'm interested how similar that is to the math I used for my Graph3DP 3D graphing utility for the Casio Prizm, though I was working in C rather than ASM. I am further curious how you do face-sorting and occlusion, if you have the patience to discuss a few details about it. I noticed what appears to be tearing between two triangles in the cube example, but I assume that that is unavoidable due to have the same texture on adjacent triangles.

The engine only runs basic back-face culling, which is yet to be fully implemented *embarrassed*. It does fail when faces are perpendicular to the viewers direction. As far as depth sorting is concerned i just use a simple sort based on the average z value of each face (polygon). I will need to fix the BFC code in an upcoming release.

I also need to add polygon clipping. At present polygons that have an endpoint outside of the screen are culled completely, you can see this when zooming in.

The tearing is due to the fact that the 'fill patterns' are naturally aligned horizontally, but not vertically. Actually just thinking about it, there might be a very simple fix for this, definitely something i should take care of.

EDIT - fixed!

Any plans for user-defined "textures"/stipple patterns?

Well actually that would be kind of handy and useful for users. I dont think that would be too hard to implement either.

Cool! Smiley-faced cubes and beyond!

I actually had made a smiley face pattern , but there is no perspective or actual mapping of the pattern to the face (its not a texture) so it kind of looks weird.

Makes sense, though I was assuming they were having some kind of mapping from the appearance of tearing in the first screenshots.

Tiny update, some basic lighting effects:

What sorts of shading are you trying out there?

Well basically i just get the angle between the face and the camera and use that as index for a set of simple patterns (black dithered to white).

Are you assuming one light in the scene (positioned by the camera) or something like that?