Closed slimsag closed 8 years ago
comaldave
commented
10 years ago The blender exporter I used was a bit problematic, it did not support all block types. I had to use the debugger to identify the offending block and skip it in my program. The linked list was a bit tedious as well. The code I wrote was not generic, it is specific to my particular blender file. Would it be better to wrap assimp?
dskinner
commented
10 years ago Blender supports python plugins, one of which I would assume is -- as being
referred to here -- a plugin for exporting the current scene to a json file
that azul3d could then use to build out a series of gfx.Objects. This
would be more of a bottom - up approach where the maintainer would continue
to export things as needed while mapping them appropriately for import.
Personally, having yet another 3D format doesn't seem like the way to go but I think the issue is pretty open to interpretation. If I'm programming in Go and happen to know someone that works with LightWave 3D for a living and wants to help out, then they'll need to export to a format that imports into blender without too much fuss and inspect the result and then export again.
Solely targeting Blender (which is a fantastic project) may be creating an unnecessary middleman. Solely targetting a single 3D modelling environment, like blender, may make it easier to support various intricacies of that particular modelling program making certain types of results easier to achieve.
On Sat, Aug 9, 2014 at 7:58 AM, David Skinner notifications@github.com wrote:
The blender exporter I used was a bit problematic, it did not support all block types. I had to use the debugger to identify the offending block and skip it in my program. The linked list was a bit tedious as well. The code I wrote was not generic, it is specific to my particular blender file. Would it be better to wrap assimp?
— Reply to this email directly or view it on GitHub https://github.com/azul3d/issues/issues/12#issuecomment-51685929.
slimsag
commented
10 years ago The goal of the JSON format is to be very easily written out. The idea is that JSON is a very easy and simple format -- so writing exporters in any modeling program would be an (mostly) trivial task.
But JSON is not very good filesize-wise for storage of 3D models, it's also probably slow to parse than binary data. So we will offer a tool that will take those JSON models and convert them to binary ones (this could make a huge difference with a game using a lot of models). I hope to write a Blender export script to this JSON format, which would ideally support most Blender features pretty well.
But obviously -- not everybody uses Blender or wants to use yet-another-model-format. Originally I intended to use Assimp to load models directly. It supports a wide range of model formats. But the assimp project actually recommends that you do not do this, because of the added processing time. Instead, they recommend that you use Assimp to convert models of any standard format, into one that best suits your engine (this is what drove me to go the JSON/Binary route).
Hopefully, we can have:
Assimp would probably come a bit later, in the mean time we can use Blender as an intermediary as @dskinner had already said.
comaldave
commented
10 years ago Wow! I think I really like where you are going with this. It would be turning blender into into a graphic designing front-end for our azul3d game engine but later allow import of most any other graphic asset. This is really in keeping with my original intent in using blender.
I know that for me, there was quite a lot in the blender file that i was not concerned with. Traversing through the linked lists was a pain because I had to figure out the structure of each record and decide what properties were important for my game, and then write a conversion from the blender to the azul3d. This was triply hard for me as i did not understand azul3d and was new to most of the graphics concepts.
The blender file I created for my senet game has only 4 types of object, a total of 15 objects, a camera and 2 light sources, had 3798 linked data blocks. There are 626 different types of blocks in the blend file. I only partially converted a few. This is a project that does not have to be 100% complete to be useful but it seems to me to be a huge project on its own.
My personal goal at the time was to convert only enough of the linked tree commencing with the blocks named for the assets I wanted to display. So step one was loading all loadable blocks into memory, Step two was to search for the blocks that I considered to be blocks of interest. Step three was to figure out what to do with the data in the block.
Somewhere in step three, I went to work on procedural graphic primitives and created what I needed for my game and never went back to blender.
I really would like to have better graphics for my game. I am willing to help create the tools. Not sure how much if any help i can be.
On Mon, Aug 11, 2014 at 5:08 PM, slimsag notifications@github.com wrote:
The goal of the JSON format is to be very easily written out. The idea is that JSON is a very easy and simple format -- so writing exporters in any modeling program would be an (mostly) trivial task.
But JSON is not very good filesize-wise for storage of 3D models, it's also probably slow to parse than binary data. So we will offer a tool that will take those JSON models and convert them to binary ones (this could make a huge difference with a game using a lot of models). I hope to write a Blender export script to this JSON format, which would ideally support most Blender features pretty well.
But obviously -- not everybody uses Blender or wants to use yet-another-model-format. Originally I intended to use Assimp to load models directly. It supports a wide range of model formats. But the assimp project actually recommends that you do not do this, because of the added processing time. Instead, they recommend that you use Assimp to convert models of any standard format, into one that best suits your engine (this is what drove me to go the JSON/Binary route).
Hopefully, we can have:
- A JSON format that is easy to read, and easy to write direct exporters to.
- A Binary/GOB format that is quick to load and has a small file size.
- A tool to convert the JSON format to Binary format.
- An Assimp loader to convert any standard (Collada, etc) model to our JSON or Binary format.
Assimp would probably come a bit later, in the mean time we can use Blender as an intermediary as @dskinner https://github.com/dskinner had already said.
— Reply to this email directly or view it on GitHub https://github.com/azul3d/issues/issues/12#issuecomment-51847742.
slimsag
commented
9 years ago I want to give an update on the status of this issue after @shurcooL brought it up on the mailing list recently.
For the model format I have a few stringent requirements that no other model format has fulfilled yet today (that I am aware of):
azul3d.org/native/assimp libassimp (Asset Importer) bindings to load any existing 3D model format into Go.
dmitshur
commented
9 years ago Hey @slimsag, thanks for a detailed explanation and update.
What you describe sounds like a valid plan.
I asked the question because I was looking for a more short term solution of loading Collada files in Go so I can render them. I think loading Collada format is still a valid need, at the very least to load and convert to another format. It seems there are 2 approaches to achieve that, through libassimp (this is the first time I hear of that project, but it looks quite good, but it's not in Go so a wrapper is needed) or through a native Go package for loading Collada only.
In the past I've tried github.com/go3d/go-collada/... packages, but they turned out to be unfinished and not working.
Just now I've found a fork github.com/GlenKelley/go-collada by @GlenKelley that seems to actually be more complete. I was able to compile another package (carsim) that uses it and see it in action:
That suggests to me that the Go Collada loader is usable to some degree (at the very least for basic models; which is probably enough for me for now), so I will probably consider using that for now.
slimsag
commented
9 years ago @shurcooL nifty screenshot :smile:
I think loading Collada format is still a valid need, at the very least to load and convert to another format.
Absolutely, and I am interested in a pure Go Collada parser as well. I can't allocate much time to working on one myself, though.
It seems there are 2 approaches to achieve that, through libassimp (this is the first time I hear of that project, but it looks quite good, but it's not in Go so a wrapper is needed) or through a native Go package for loading Collada only.
I found my half-baked libassimp Go wrapper, when I was last working on it it libassimp wouldn't build under MinGW (see assimp/assimp#177).
From what I briefly remember about libassimp (in case it helps):
libassimp binary is rather large file-size (if I remember correctly, about 40mb).
dmitshur
commented
9 years ago Ok, just want to give an update on the Collada loader.
I was able to use it successfully to load .dae files exported from SketchUp and render them (in a very rudimentary way for now).
(As a side note, I used assimp to convert the original source .x model file into .dae. However, since I'm porting a small game with a single 3D model and not building a full-fledged game engine, this basic approach sufficed for me for now. But I can see the usefulness of using libassimp as a general importer of many 3D formats.)
If @GlenKelley doesn't mind, I'd like to add github.com/GlenKelley/go-collada to the awesome-go list of libraries, because as far as I know it is the only working Collada library for Go. I'm willing to help maintain and develop it further.
mdaffin
commented
9 years ago You might want to look at http://msgpack.org/ very similar to json, but in a binary format instead so it is much smaller and faster.
As for compressions lzop or lz4 are very good for speed, which will help allot with loading times and also help to reduce disk space, although not as much as slower codecs like gzip.
slimsag
commented
9 years ago @james147 I appreciate the well-thought insight. I will look into those and consider them quite seriously.
slimsag
commented
9 years ago A kind fellow on Slack linked me to the following:
[]float32 and []float64 data sets (which 3D models primarily consist of) -- FPC:
xagaba
commented
9 years ago Are you aware of http://opengex.org/ ? You get 3D Studio Max, Blender and Maya in one go..
slimsag
commented
9 years ago @xagaba I am, yes. OpenGEX is not a good choice for a run-time format. It is a format for exchange between applications (hence the name Open Game Engine Exchange Format), and also by this phrase on the top of their website:
The Open Game Engine Exchange (OpenGEX) format is a text-based file format designed to facilitate the transfer of complex scene data between applications such as modeling tools and game engines.
For an exchange format, it also lacks a substantial amount of feature preservation when compared to Collada.
Seb-C
commented
9 years ago Some time ago I wrote a function to load an obj model for WebGL. I would like to translate it for azul3d, and share it here if it's OK.
Should I put it as a function in gfxutils ?
slimsag
commented
8 years ago This issue was moved to azul3d/engine#18
Azul3D will need a model loader to load animated/static 3D models and scenes. Ideally the file format would be targeted towards specifically Azul3D and would have two components, a JSON format for readability and for compatibility with other languages, and a Binary (GOB) format for quick loading into the engine.
Additionally, we will need a Blender Exporter script so that we can bring models and entire scenes from Blender straight into Azul3D.
Exporters would export just to JSON, and then a tool would be made available that allows converting from the (slow, large file size) JSON format into the (fast, small file size) Binary format.