64Digits

Let me blather on about my 3D modeler. I used it to make this:

</p>

First off, it is a low-level modeler. Low level does not mean crappy. It means that something is more hands on, less stuff is done automatically. Low level tends to take a little longer, but in the end the result is generally much better because low-level allows you to control more.

A comparison - C++ is a low-level programming language - it doesn't have all the fancy stuff that some other languages (like Java) have - no automatic garbage detection, etc. But C++, while it takes a little longer to write, is much more powerful that Java.

Similarly, this modeler allows you to manipulate and move around individual faces and vertices. Although this takes longer, you can put everything exactly where you want it, how you want it. It also allows you to do your UVMaps by hand instead of auto-generating them, so you can have complete control over that.

One thing my modeler does auto-gen is normals, but you can also change those by yourself too, if you wish.

Awesome sounding, yes. Its still pretty much unusable right now though. When I say you have to do things by hand right now, I mean by hand, because right now you have to build models via text because I have yet to produce a 3D point to 2D screen coordinate script (probably going to reverse Yourself's script) meaning you can't select nodes in the modeler itself, a core part of it.

But even so, even the text files are easy to do by hand because of the way I have it set up. Here's a sample:

DangerSign.PNG
14
[-8,1,24]//panel
[8,1,24]
[-8,1,8]
[8,1,8]
[-2,1,8]//front pole
[2,1,8]
[-2,1,0]
[2,1,0]
[-2,-1,8]//back pole
[2,-1,8]
[-2,-1,0]
[2,-1,0]
[-2,1,16]//top pole
[2,1,16]
16
[1,2,3][0,0,128,0,0,128][1]//front panel
[3,2,4][0,128,128,0,128,128][1]
[2,1,4][128,0,256,0,128,128][1]//back panel
[4,1,3][128,128,256,0,256,128][1]
[5,6,7][0,128,32,128,0,256][1]//front pole
[7,6,8][0,256,32,128,32,256][1]
[10,9,12][0,128,32,128,0,256][1]//back pole
[12,9,11][0,256,32,128,32,256][1]
[9,5,11][0,128,32,128,0,256][1]//left pole
[11,5,7][0,256,32,128,32,256][1]
[6,10,8][0,128,32,128,0,256][1]//right pole
[8,10,12][0,256,32,128,32,256][1]
[9,13,5][0,256,32,128,32,256][1]//left tri pole
[6,14,10][0,256,32,128,32,256][1]//right tri pole
[14,13,10][0,128,32,128,0,256][1]//incline
[10,13,9][0,256,32,128,32,256][1]

First line is the file for the UVmap/texture. Second line is the # of vertices, followed by the vertices themselves. Then you have the number of faces/triangles, which are read in as the format of: 3 vertices by # (1 is the first defined vertice, 2 is the 2nd, etc), and 6 UV coordinates for the texture (which must be of the size 2^n), and finally a value of to use the vertex's normals, or the face's normal (for lighting and smoothing).

Because of the ease of use of doing it via text, I've also implemented a method for commenting in the files, anything after "//" on a line is completely ignored.

So, the above code, combined with UVMap yields this:

</p>

A much larger file, with 52 vertices and 64 triangles yielded the roadblock you saw above.

I think it is going well, no?

64-Poly Delicious

Comments