Work in Progress

Teapot renderer

8

SP4CEBAR 2023-01-25 10:12 (Edited)

Thanks to @nathanielbabiak for compressing the Utah Teapot OBJ file so that the NX program is below 128 Kilobytes and can be posted


Previously
The Utah teapot file is way bigger than I thought it would be
I loaded the teapot with the string trick, but that made the NX project like 450 Kilobytes in size, so I had to cut most data out to be able to post it (an the NX file may not exceed 128Kb). So there are no faces for now, so it won't draw anything. I could try to reduce the complexity of the file in Blender

I can't rotate it yet so it may not be clear from whatever angle this is, it looks like the handle of the teapot is right and the nozzle, or whatever it's called, is left

teapot_org 2.nx | Open in app
2023-01-26 23:16
teapot_org 2.nx | Open in app
2023-01-26 22:27
teapot_org 2.nx | Open in app
2023-01-26 22:26

nathanielbabiak 2023-01-25 15:41

This is incredibly cool and very promising! But right now it stops loading at 1900 or so... can you fix it so that the screenshot loads?


SP4CEBAR 2023-01-25 19:15 (Edited)

I can only upload 128Kb to here, so I removed most of the file, there are no faces left so it can't draw anything, I need a smaller file so I probably need to reduce the number of vertices it in blender


McPepic 2023-01-25 19:21

I did some tests on the program to find out where it was getting hung up. When 'COUNT' is 1919 and 'I' is 58280, the program gets stuck in the loop after 'WORD$=""'. At this point, READ_TEXT will continue to return ascii character 0, which is null. I hope this helps @SP4CEBAR!


SP4CEBAR 2023-01-25 19:24 (Edited)

@McPepic, thanks for the effort, the truth is... I broke it on purpose: the teapot file is incomplete, I removed most of it to be able to post it here (there's a 128Kb limit)


SP4CEBAR 2023-01-25 19:30 (Edited)

If you want to complete the file for yourself, you can go to this online hex converter, untick both boxes, upload any OBJ file to convert it to hex, and copy the hex data to the big hex string in my program (inside the subprogram called LOAD_DATA)


nathanielbabiak 2023-01-26 01:14 (Edited)

What obj file are you using? One available online?

This one's smaller than Utah's.


SP4CEBAR 2023-01-26 09:06 (Edited)

@nathanielbabiak yes... I found it again: (this URL downloads the file instantly) https://graphics.stanford.edu/courses/cs148-10-summer/as3/code/as3/teapot.obj


SP4CEBAR 2023-01-26 10:13 (Edited)

If it doesn't appear right you can search for "X=VERTEX(0)+6" in my program to change the X,Y, and Z offsets (in this case the X offset is "+6") I should put this into the matrix at some point

If you want to rotate it, you need to search for "CALL ROTX_MATRIX(M(), 0.6*PI, 2)" and uncomment it, it has two parameters: the first one is the angle to rotate, and the second one is the dimension: 0 (rotate around x), 1 (rotate around y), or 2 (rotate around z), it may not rotate the direction you think it should rotate, and the starting direction (A=0) may not be where you think it is, (I may have put the sine, cosine, and -sine, and another cosine in the wrong order) but it will rotate just fine

I updated the program to add the rotation logic


GAMELEGEND 2023-01-26 13:09

I got a model of a dragon, and it made the file 23,094 KB XD


SP4CEBAR 2023-01-26 16:26 (Edited)

@gamelegend You can try to load it, you won't be able to post it, but it should work (the program uses the infinite memory in a string trick)

Also, it may be scaled too big, coordinates in the thousands are probably not seen by the camera


GAMELEGEND 2023-01-26 16:49 (Edited)

I got an index out of bounds error.


nathanielbabiak 2023-01-26 19:47 (Edited)

I've taken the teapot dataset and organized all the values. The attachment on this post does a few things described below, ultimately allowing the full dataset to be uploaded in 120 kB. You'll have 8 kB remaining for code.

For the vertices, each coordinate is now represented as a fixed-point 16-bit value (neither a float nor an integer). The min and max values are -4.00000 and +3.99988. (If you look at the hex dump, interpreting those values as signed integers, it'd be -32768 and +32767. These are "special" values you might find familiar.) This allows each XYZ point to be represented as twelve hex digits (rather than approx. 60).

For the faces, each index is now represented as a unsigned 16-bit integer. This allows each triple to be represented as twelve hex digits (rather than approx. 30).

The downside of this approach is: loading native obj files (ASCII) won't be possible unless they're "organized" into this format. I used Excel to do it. But, since obj files are already too large to load, it's kind'a moot, right?

Anyway, could you incorporate into your original post, or help me understand where I should look in your code to do that? You just need to set your global array of points and faces where I've indicated in the attached comments. It'd be like 100 times faster if you did than me, since you're more familiar with how to do it...

teapot_org.nx | Open in app
2023-01-26 19:51

SP4CEBAR 2023-01-26 21:29

@gamelegend, I didn't think about that, the array sizes are tuned for the teapot, so you could just search for DIM, and replace every big number with an even bigger number


SP4CEBAR 2023-01-26 21:31

@nathanielbabiak, thank you, I'll look into it, and organize and document my code a bit


SP4CEBAR 2023-01-26 22:28 (Edited)

Done, the smaller file size made it much faster


SP4CEBAR 2023-01-26 22:36 (Edited)

Here's a version with filled triangles, the triangles seem to shoot out a bit too much, maybe the pixels need to be clamped (relatively flat lines make inaccuracies of the line direction value noticeable)

teapot_org.nx | Open in app
2023-01-26 22:36

SP4CEBAR 2023-01-26 23:16

Points look way better than lines


McPepic 2023-01-27 00:00

Cool stuff! Are there any plans to write a converter in order to use other models?


nathanielbabiak 2023-01-27 01:44 (Edited)

McPepic, not easily. If Spacebar makes a console tool (he's already written an obj file reader), it would be limited to 5461 entries (combined total of vertices and faces). (Each vertex or face would take 6 bytes, it'd be just below the 32 kB limit.) From a quick Google search, there does not appear to be an easy way to change the triangle mesh size unless you have a 3D modeling program.

The organization still requires use of the infinite memory trick, which cannot be edited with a console "tool". You can use Excel, Google Sheets, Open Office, or Libre Office to do it though! Here's how to do it. Vertices are first, then faces:


McPepic 2023-01-27 01:57

@nathanielbabiak
I realize that you can't use a tool in NX to convert the .obj.
I was thinking that it would be possible to program a converter in a separate programming language that would output the formatted data.
I was thinking of trying for myself to get a tool like that working and wanted to make sure no one else was doing it already.


nathanielbabiak 2023-01-27 02:00

Cross post!

I've been editing my response. Re-read the intro, it's possible but limited.

To your point, yes, it's not a really bad set of steps to follow... Good luck! :-)


SP4CEBAR 2023-01-27 09:17 (Edited)

You can make a tool that does it, you just can't post it with the original teapot file due to the 128KB limit, edit: oh wait, there's no easy way to output the file, you have to do it with one disk at a time


SP4CEBAR 2023-01-27 09:56

@nathanielbabiak To make an NX program for the conversion I interpreted your steps like this:
1. Done
2. IF VALUE>=-3.99999 AND VALUE<=3.99999 THEN
3. VALUE=INT(VALUE*8192 +0.5)
4. VALUE$=HEX$(VALUE,4)
5. the program has already filtered the line breaks out
6. It just needs to store the loop iteration value when it's done


SP4CEBAR 2023-01-27 10:13 (Edited)

v$=v$+value$ gets slower over time, so I use mid$(v$,count*4,4)=value$ instead, in the beginning v$ is loaded with 10000 spaces:


SP4CEBAR 2023-01-27 10:27

@mcpepic thanks for the testing you did in this post, I just fixed it and it will now terminate the loop when there's no more data to read


SP4CEBAR 2023-01-27 10:48

My converter made data that looks like this:
00A09A39000045A09A3968FD45A09A39
Instead of this:
A000399A0000A045399AFD68A045399A


SP4CEBAR 2023-01-27 10:55 (Edited)

It looks like this is caused by the order of POKEW, because PEEKW is able to reconstruct the data
now I see it: If the first set is AABBAABBAABB, the second set is BBAABBAABBAA (in the previous post)


SP4CEBAR 2023-01-27 11:22 (Edited)

It now looks like this:
A000399A0000A145399AFE68A145399A
Which has some rounding errors compared to this:
A000399A0000A045399AFD68A045399A
Interestingly the previous attempt didn't have these rounding errors:
00A09A39000045A09A3968FD45A09A39


SP4CEBAR 2023-01-27 11:36

Running V=VV AND $FFFF before splitting the value into bytes fixed it


SP4CEBAR 2023-01-27 11:57

@nathanielbabiak you don't need to manually define the sizes, this also works:
VQTY=LEN(V$)\12
FQTY=LEN(F$)\12


Log in to reply.