3D SGL export script for blender

RockinB

Established Member
Today I started making an export script for my favorite free 3D modeling tool blender. It's a python plugin which currently doesn't use any external python modules.

The output looks quite good:

Code:
/* Generated with:

 * SegaSaturn.py - python script for blender to export to SGL format.

 * by The Rockin'-B, [url]http://www.rockin-b.de[/url]

 */

// Exporting 3 objects

// Exporting object...name: Cube, type: Mesh

// Number of vertices: 8

POINT	point_Cube[] = {

	POStoFIXED(1.0, 0.999999940395, -1.0),

	POStoFIXED(1.0, -1.0, -1.0),

	POStoFIXED(-1.00000011921, -0.999999821186, -1.0),

	POStoFIXED(-0.999999642372, 1.00000035763, -1.0),

	POStoFIXED(1.00000047684, 0.999999463558, 1.0),

	POStoFIXED(0.999999344349, -1.00000059605, 1.0),

	POStoFIXED(-1.00000035763, -0.999999642372, 1.0),

	POStoFIXED(-0.999999940395, 1.0, 1.0),

};

// Number of faces: 6

POLYGON	polygon_Cube[] = {

	NORMAL(0.0, 0.0, -1.0), VERTICES( 0, 1, 2, 3)

	NORMAL(0.0, 0.0, 1.0), VERTICES( 4, 7, 6, 5)

	NORMAL(1.0, -2.83122062683e-07, 4.470341608e-08), VERTICES( 0, 4, 5, 1)

	NORMAL(-2.83122062683e-07, -1.0, -1.04308199411e-07), VERTICES( 1, 5, 6, 2)

	NORMAL(-1.0, 2.23517446329e-07, -1.34110436534e-07), VERTICES( 2, 6, 7, 3)

	NORMAL(2.38418579102e-07, 1.0, 2.08616256714e-07), VERTICES( 4, 0, 3, 7)

};

// Number of faces: 6

ATTRIBUTE	attribute_Cube[] = {

	ATTRIBUTE(Single_Plane, SORT_CEN, No_Texture, C_RGB(0, 0, 0), No_Gouraud, CL32KRGB, sprPolygon, No_Option),

	ATTRIBUTE(Single_Plane, SORT_CEN, No_Texture, C_RGB(0, 0, 0), No_Gouraud, CL32KRGB, sprPolygon, No_Option),

	ATTRIBUTE(Single_Plane, SORT_CEN, No_Texture, C_RGB(0, 0, 0), No_Gouraud, CL32KRGB, sprPolygon, No_Option),

	ATTRIBUTE(Single_Plane, SORT_CEN, No_Texture, C_RGB(0, 0, 0), No_Gouraud, CL32KRGB, sprPolygon, No_Option),

	ATTRIBUTE(Single_Plane, SORT_CEN, No_Texture, C_RGB(0, 0, 0), No_Gouraud, CL32KRGB, sprPolygon, No_Option),

	ATTRIBUTE(Single_Plane, SORT_CEN, No_Texture, C_RGB(0, 0, 0), No_Gouraud, CL32KRGB, sprPolygon, No_Option),

};

// Number of vertices: 8

VECTOR	normal_Cube[] = {

	POStoFIXED(0.0, 0.0, 0.0), // ERROR: in writeNMesh_vntbl

	POStoFIXED(0.0, 0.0, 0.0), // ERROR: in writeNMesh_vntbl

	POStoFIXED(0.0, 0.0, 0.0), // ERROR: in writeNMesh_vntbl

	POStoFIXED(0.0, 0.0, 0.0), // ERROR: in writeNMesh_vntbl

	POStoFIXED(0.0, 0.0, 0.0), // ERROR: in writeNMesh_vntbl

	POStoFIXED(0.0, 0.0, 0.0), // ERROR: in writeNMesh_vntbl

	POStoFIXED(0.0, 0.0, 0.0), // ERROR: in writeNMesh_vntbl

	POStoFIXED(0.0, 0.0, 0.0), // ERROR: in writeNMesh_vntbl

};

XPDATA	xpdata_Cube = {

	point_Cube, sizeof(point_Cube)/sizeof(POINT),

	polygon_Cube, sizeof(polygon_Cube)/sizeof(POLYGON),

	attribute_Cube,

	normal_Cube,

};

OBJECT	object_Cube = {

	(PDATA *)xpdata_Cube,

	TRANSLATION(0.285713672638, -0.190474033356, 0.0),

	ROTATION(0.0, 0.0, 0.0),

	SCALING(1.0, 1.0, 1.0),

	NULL,

	NULL,

};

The challenge is to map the Saturn specific display attributes in a smart way. Some attributes are not completely supported yet. So it's still WIP and just for your information.

To those who may ask "Why this?":

It's meant to be a 2nd way besides using 3DEditor.

You can't change geometry in 3DEditor, only material properties. Applying geometry changes must thus be done in a sepertate 3D modeling tool. Then all work done with 3DEditor before is lost.

My texture coordinate mapping stuff could be formed to a commandline tool to even have a 2nd way for the texture mapping precomputation of 3DEditor's tool "Texture List".
 
For my contest entry, I'm currently improving the SGL export script for Blender (3d modeling program), that I wrote back in summer 2005.

I removed some errors, added coordinate system conversion and made it possible to export all or just selected objects.

Next I will:

- add support for linked data (saves memory for equal objects)

- preserve the object hierarchy

- add some Level Of Detail support

- support for texture export (either directly or through a tool that I can derive from my Texture Coordinate stuff)

Finally I'd like to:

- finish the gouraud support for both real time and static gouraud

- find out a way how Saturn specific attributes can be defined and exported
 
done:

- add support for linked data (saves memory for equal objects)

- preserve the object hierarchy (objects that are not selected for export, but required for exported objects hierarchy to be complete, these objects are empty, only position, rotation and scale is exported)

- added a pointer to the first root object to start rendering the whole scene

It's amazing what can be done with Blenders Python interpreter. I decided that I will support texture export by the export plugin directly. But I'm unsure if I will generate textures manually like I did it in the TextureCoordinate stuff. Because this would only work for image type textures, not for all the other procedural textures that blender supports (for these ones, I can't access individual texels in python...).

So better option would be to render the texture using BGL and than export the result. This would benefit from texture filters, that I would have to implement manually in software, when using the other method.

I still need to find a smart way to determine individual texture dimensions.
 
Sorry, my browser crashed when I wrote this posting the first time. Too lazy to write it again.

The rushed-out first release of the blender SGL export plugin is attached to this post. Next one on Monday.

Feedback is recommended, if you got a feature request, tell me.

Note: I used blender 2.37a

# release notes / change log:

# a plus '+' designates a feature, a minus '-' a bug or missing feature

# 06/12/01:

# + comes with Saturn demo code (slPutObjectX(), slPutAllObjectsX(), no real time gouraud yet supported)

# + supports objects with no material assigned,

# then it will create sglDummyMaterial (if it does not already exist) and use that one.

# The sglDummyMaterial remains unlinked, it's not assigned to any object

# + supports faces with only 3 (triangles) vertices instead of 4 (quads),

# in this case, vertex 4 is equal to vertex 3

# + converts coordinate systems automatically (OpenGL to SGL):

# Blender -> Saturn

# x -> x

# y -> -z

# z -> y

# + supports hierarchy, uses SGL's OBJECT structure, which got links to children and siblings

# + preserves hierarchy when the selection covers only a subgraph of the hierarchy,

# for all unselected objects that still need to be present in the hierarchy, only their object

# transformations are exported, not it's 3d data

# + creates a pointer link to the topmost OBJECT, when starting to render OBJECTS recursively, all OBJECTs can be drawn

# + supports export of gouraud tables

# + does not require a full python installation

# - no texture export yet

# - gouraud feature (and a lot more) untested, only static gouraud created by manually assigning vertex colors

# can be expected to work correctly

# - script only tested with blender 23.7a on MacOS X

# - rushed out
 

Attachments

  • BlenderSglExportScript_061201.zip
    390.9 KB · Views: 183
Well done Rockin :) It has to be added in the Saturn dev sections. I'm a bit late for the updates.
 
Well, only one download. VBT, I guess you would like to see SBL export support?

Here is the 2nd release, a lot of features have been added and improved. Most importantly, static and realtime gouraud, support for multiple materials per object, as well as texture support. This goes for both, the plugin and the Saturn demo.

# release notes / change log:

# a plus '+' designates a feature, a minus '-' a bug or missing feature

# 06/12/04:

# + exports to 3 files:

# <filename>.mdl <- 3d object hierarchy polygon data

# <filename>.gr <- gouraud tables, definitions and variable declarations (static and real time)

# <filename>.txr <- character pattern data, TEXTURE table, PICTURE table

# + texture export:

# recognizes h/v flipped textures and avoids duplicates,

# exports character pattern tables, TEXTURE table and PICTURE table,

# demo supports texture display

# - texture export currently only works for image textures that got UV coordinates assigned (manually)

# + gouraud: switched VRAM position of real and static gouraud,

# added macro definitions for DMA target address for the gouraud tables,

# fixed setting of flag CL_Gouraud, it must be set for static and real time gouraud

# (warning: gouraud does not yet work in yabause 0.7.2, but on real Saturn),

# added macro definitions and variable declarations needed for real time gouraud,

# fixed vertex normal export,

# added static and real time gouraud shading to demo

# + default filenames are taken from the .blend filename instead of always being untitled.mdl

# + discovered & fixed: multiple materials used by a single object work now,

# even if the material is not contained in the NMesh's list, but in the Object's list

# + fixed: object scale's coordinate system wasn't converted to Saturn coordinate system

# + fixed: converted object rotation from radiants to degrees
 

Attachments

  • BlenderSglExportScript_061204.zip
    757.2 KB · Views: 187
RockinB said:
Well, only one download.

Maybe the info is wrong I have downloaded the new release today twice and there is still written 0 view.

VBT, I guess you would like to see SBL export support?



Not sure or maybe later, I tried 3D only with the SGL. Thanks for the update I've already added it in the dev section :)
 
Sure, one "downside" is that people need to get familiar with blender first, before using my plugin. When you work with 3d graphics, you usually are familiar with some 3d modeling tool, be it blender or some other.

As blender supports import and export of various file formats, there is no need to model the entire stuff in blender.

At this point, where I'm coding the plugin, I cannot present you Saturn screenshots that give an impression of the potential of this tool. But when I start using it for my entry (and when I got some more sophisticated 3d models), I will provide some screenshots that will convince (at the very least, if not impress) the people, especially those who tried the painfull (but working) 3DEditor method.

Oh, by the way: my current texture export approach is to automatically approximate a given VRAM size constraint. This works like: you want to allow the plugin to use 256 kB (for example) of texture RAM and the plugin determines individual texture sizes (when resampling is needed) such that it uses as much space as it needs and as it got available.
 
Recently I've been working on the texture export. I could remove some bugs and add features.

When I have improved the texture size determination, I will add a bilinear filter option, most likely add a gui, do further tests/verifications of texture export, clean the code and then I will release the next version on friday.
 
I've been working a lot on the texture export, it finally works very well (and got a bilinear filter, too). The script also got a little bit of graphical user interface using pop-up input widgets and a progress bar (texture export can take a while). The settings are saved and restored when blender is closed and reopened.

I made some screenshots, see the attachment.

The transformation problem with hierarchies is still not removed, but can be worked around when applying the transformations to the mesh or when not using deep hierarchies. The archive contains the old source code of the Saturn demo (forgot to update), but new ISOs. The script should be quite usable at this point. As for texture export, only a few little improvements can be done in texture width computation.

Enjoy it!

# release notes / change log:

# a plus '+' designates a feature, a minus '-' a bug or missing feature

# 06/12/08:

# + added progress bar

# + settings allowed:

# via pop-up menus, changed settings are saved in the registry and are automatically restored later

# + added bilinear texture sample filter

# + fixed texture sampling to sample the nearest neighbor

# + added custom integer sqrt, if math package not present

# + for smart texture size determination:

# texture weight is now it's area, not it's surrounding,

# texture width and height is now determined by the polygon shape,

# added setting of maximum for width and height (because yabause doesn't display 504px width textures),

# max width and height are further restricted by the pixelspace the subtexture occupates on the source image size

# -> beware, yabause doesn't yet support textures of maximum width 504, but real Saturn does,

# fixed an error in texture sampling (y_add was wrong), fixed another error which could cause pixels being outside image
 

Attachments

  • yabause_nearest.jpg
    yabause_nearest.jpg
    29.1 KB · Views: 134
  • yabause_bilinear.png
    29.1 KB · Views: 139
  • blender.jpg
    blender.jpg
    29.1 KB · Views: 206
  • BlenderSglExportSaturnDemo_061208.zip
    477.8 KB · Views: 196
  • BlenderSglExportScript_061208.zip
    477.8 KB · Views: 208
Wow really nice results, the Sonc/Knuckles texture looks to have a high quality !!! I did some tests on Girigiri and Satourne, here is how it looks
 

Attachments

  • RockinBdemoSatourne.jpg
    RockinBdemoSatourne.jpg
    125 KB · Views: 143
  • RockinBdemo.jpg
    RockinBdemo.jpg
    125 KB · Views: 160
vbt said:
Wow really nice results, the Sonc/Knuckles texture looks to have a high quality !!! I did some tests on Girigiri and Satourne, here is how it looks

Cool, thanks for the screenshots. The lower Sonic&Knuckles texture got 128x128 texels. Do you see the upper one? This is a square grid of 7x7 polygons, so 49 small textures. You see that they got a quite low vertical resolution. That's due to the horizonal resolution which is fixed to multiples of 8. So actually, the horizontal width is bigger than it would be optimally, so the vertical res is reduced, because it is only allowed to consume a certain number of texels.

That's a point where an improvement of the texture size determination could give a better result. Currently, this can be worked around by assigning a lot of texture memory and possibly restricting maximum texture size, then it won't take all memory granted and the texture height is increased.
 
RockinB said:
Cool, thanks for the screenshots. The lower Sonic&Knuckles texture got 128x128 texels. Do you see the upper one? This is a square grid of 7x7 polygons, so 49 small textures. You see that they got a quite low vertical resolution. That's due to the horizonal resolution which is fixed to multiples of 8. So actually, the horizontal width is bigger than it would be optimally, so the vertical res is reduced, because it is only allowed to consume a certain number of texels.

Ok I didn't really see that on Girigiri but it can bee seen on yabause(picture attached), Also is there something special in the polygon on the right (see second pic) ?
 

Attachments

  • yabause.jpg
    yabause.jpg
    77.8 KB · Views: 164
  • special.jpg
    special.jpg
    77.8 KB · Views: 158
vbt said:
Ok I didn't really see that on Girigiri but it can bee seen on yabause(picture attached), Also is there something special in the polygon on the right (see second pic) ?

The gaps (black lines) between the textures and the little displacement comes from the emulator.

The cone on the right uses static gouraud shading, every vertex got a custom assigned color, done with vertex paint mode in blender. Such stuff can look nice, eh?

BTW: The gouraud shading is not displayed by Yabause, but works on real Saturn (same for 504px width textures, that's why I've implemented custom pixel size restriction via gui).
 
Recently, I added support for transparent pixels in textures, using a customizable alpha threshold value.

Well, most of the work that has been done is for the texture stuff. Still some room for improvement, especially when it comes to save texture memory. Some optimizations of this kind are already in, but I still have ideas left. Hopefully my C4 entry will demand the remaining optimizations, such that I have a good reason to put them in.
 
Piratero said:
Excellent work! I may just have to read up on 3D so I can make some use of this script!

Thanks :)

Raster said:
I wonder if this could easily be modified to support systems like the PSX and N64?

In theory, you can write an export plugin for whatever system you like. Blender uses python, I like that language. Currently, the plugin needs a code cleanup and the biggest part of it, the texture export, applies only for sprite based system. For N64 and PSX I guess the texture export is much easier.

I suggest starting from a simple existing export plugin like the VRML one (I did that and I had first results the first day I started).
 
Back
Top