Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / 3D Exporters for AGK 3D file format

Author
Message
RickV
TGC Development Director
24
Years of Service
User Offline
Joined: 27th Apr 2000
Location: United Kingdom
Posted: 18th Jul 2012 00:01
Link
Hi,

As you probably know we are developing the 3D engine for AppGameKit and work on this is going well. We have decided to create our own internal 3D engine format (a bit like Dark Basic Pro's DBO format).

When we are ready we will publish the details of the AppGameKit 3D format. It will then be possible for users to create exporters for modelling tools. We are wondering if anyone in the community will be up to the challenge of creating said exporters while we continue to refine the main 3D system?

Let us know in this thread if you think you can help.

Cheers,

Rick

Financial Director
TGC Team
Back to top
Profile PM Email Website
3d point in space
14
Years of Service
User Offline
Joined: 30th Jun 2009
Location: Idaho
Posted: 18th Jul 2012 02:31 Edited at: 18th Jul 2012 07:37
Link
do you want the said person to know opengl. Because There is a difference in making an exporter for opengl and direct x. Their is so little detail on what you want. I only know old opengl 3d exporters. I currently making something else my sprite engine in mfc so don't know if i can do both. The only exporter that I played with in opengl did 3ds format.
I will be adding xml 3d objects in my engine but it is done in dark gdk. I was thinking that 2d xml engine wont be that much different then 3d. The objects will be 3ds format therefore all the animation can be controlled by xml. I think there is a .x to 3ds convertor somewhere.
Here is an example of the file format that can be animated as 3ds format with 3ds objects that I am making know.


Developer of Space Chips, pianobasic, zipzapzoom, and vet pinball apps. Developed the tiled map engine seen on the showcase. Veteran for the military.
Back to top
Profile PM Email Website
MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 18th Jul 2012 03:50
Link
What is mfc?

Will tjis tool be bundled with AppGameKit 3D?

(sorry for being kinda off topic but curious about my future investment...)

Back to top
Profile PM
3d point in space
14
Years of Service
User Offline
Joined: 30th Jun 2009
Location: Idaho
Posted: 18th Jul 2012 03:53
Link
No it won't be bundled with agk. They want a exporter tool and the only one i can think of is 3ds. So I working towards this in dark gdk because I understand opengl file format a little. 3ds file format can't animated so I proposed to have objects be animated with xml.

Developer of Space Chips, pianobasic, zipzapzoom, and vet pinball apps. Developed the tiled map engine seen on the showcase. Veteran for the military.
Back to top
Profile PM Email Website
MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 18th Jul 2012 04:00
Link
So we have to pay for it? Or it is free... If we have to pay for it on top of AppGameKit 3D... Pft...

Back to top
Profile PM
3d point in space
14
Years of Service
User Offline
Joined: 30th Jun 2009
Location: Idaho
Posted: 18th Jul 2012 04:22
Link
Well i haven't made it yet but I know how to. I don't know if I can get it done before I go to grad school this next semester. And if they do use my tool yes I will charge for it, but I am looking for people here on the forums to help me with this tool also. I also know 3ds is a common format that they would probably use and my tool is going in that direction any way.

Developer of Space Chips, pianobasic, zipzapzoom, and vet pinball apps. Developed the tiled map engine seen on the showcase. Veteran for the military.
Back to top
Profile PM Email Website
Airslide
19
Years of Service
User Offline
Joined: 18th Oct 2004
Location: California
Posted: 18th Jul 2012 05:58
Link
Writing a file-format exporter shouldn't be any different for OpenGL or DirectX, unless your original format is dependent upon one of those (such as .X). The exporter should just be taking data in whatever format the 3D modeling app provides and converting it to AGK's format using whatever plugin pipeline/architecture is in use by the app.

Knowledge of a rendering API should not be necessary, as you are dealing with raw data. The only time you need to work with either of those frameworks is when you are loading the data and uploading it to the GPU (or providing it to the API in some other manner). This is what will be happening internally in AppGameKit, but it should not need to happen during the export process in the modeling software.
Back to top
Profile PM Email
Dar13
15
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 18th Jul 2012 06:05 Edited at: 18th Jul 2012 06:12
Link
Quote: "What is mfc?"

Microsoft Foundation Class Library, a set of libraries made for helping Win32 GUI development.

Quote: "When we are ready we will publish the details of the AppGameKit 3D format. It will then be possible for users to create exporters for modelling tools. We are wondering if anyone in the community will be up to the challenge of creating said exporters while we continue to refine the main 3D system?
"

I'm interested, but I'm a bit caught up in a few projects of my own so I'm not sure when I'll be able to devote any amount of time to it.

Follow WTLD's progress on Twitter
Git repository for WasTeLanD
Back to top
Profile PM Email
MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 18th Jul 2012 06:07
Link
Mega thank you Dar13

Back to top
Profile PM
BraindeaD
16
Years of Service
User Offline
Joined: 30th Mar 2008
Location:
Posted: 18th Jul 2012 10:20 Edited at: 18th Jul 2012 10:42
Link
Hi all,
sure the new format will be awesome but, why not use the original dbo format in the beginning? It's well known by the developers, supports lightmaps and other features and there are lots of programs with dbo export option?
Just curiosity.

Best regards
Back to top
Profile PM
anwserman
12
Years of Service
User Offline
Joined: 20th May 2011
Location: Wisconsin
Posted: 18th Jul 2012 10:50
Link
That or FBX. This could turn into a scenario of 'great idea now but we'll have to support a new format later due to customer demand'. Unless there is great support for this new format, it will kill any change AppGameKit 3D has from the get-go.

Hi there. My name is Dug. I have just met you, and I love you.
Back to top
Profile PM Email Website
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 18th Jul 2012 11:06
Link
propriety formats will lead to 1000 problems. 1 of them is that we will be stuck to this one converter, with all of its problems. another problem is that all 3rd party tools will be made useless.

with darkbasic one would use any 3rd party exporter and output to .x

i would suggest using industry standard formats like .obj or fbx
Back to top
Profile PM Email
The Zoq2
14
Years of Service
User Offline
Joined: 4th Nov 2009
Location: Linköping, Sweden
Posted: 18th Jul 2012 11:20
Link
Does this mean AppGameKit will only support this format?
Back to top
Profile PM Email
MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 18th Jul 2012 11:25
Link
I think something needs clearing up... From what I can understand

A single format will both help in reducing compatibility issues and debugging... As well as reducing application file sizes and possible overheads of loading and manipulating multiple formats... These are not high end processors though powerful...

Can someone confirm anything I have said as being any bit valid?

Back to top
Profile PM
anwserman
12
Years of Service
User Offline
Joined: 20th May 2011
Location: Wisconsin
Posted: 18th Jul 2012 11:32 Edited at: 18th Jul 2012 11:50
Link
Quote: "A single format will both help in reducing compatibility issues and debugging... As well as reducing application file sizes and possible overheads of loading and manipulating multiple formats... These are not high end processors though powerful...
"


Yes. It depends on the format though.

What it seems like is that they're developing AppGameKit with it's own proprietary 3D format. That's the problem, and I do not like the sounds of it.

Why?

1) It's going to be a new file-format. Which means no external support through outside applications (MS3D, Fragmotion, or even major apps like 3DS Max or web applications like Mixamo)
2) TGC is looking to out-source the programming to external programmers to develop plug-ins for this new format. This means that the quality of export/import options is based upon 3rd party work (this means that if your favorite modelling tool has no plugin support for this format, you'll have to write it yourself or SOL).
3) My fear is that TGC will create this format, and then due to customer demand, support another format as well. Thus, we now have two file formats to support in the engine, twice the problems will crop up eventually down the road, and this whole mess was for nothing.
4) This will kill AGK's userbase, because people interested in AppGameKit will notice that it only supports this proprietary file format, and then pass on the toolkit

Look at Dark Basic Pro. It supports .X, .DBO, and a handful of other file formats. From what I've heard, .DBO had its flaws and was only supported by ONE development language, making it highly coupled with the coding. Plus none of my tools supported it. So I went with .X, which I've used before and most familiar with.

EDIT: I hate going on these rants, I really do. I love AppGameKit - even with it's flaws - and that without it, I would not have sold or developed ANY apps for mobile devices (i'd be $400 poorer ). It's just that, after using DBPro and seeing the custer-fark that became with plug-ins implementing core features that should have been there to begin with (IMO), and feature-overload that created a bunch of options (but none of them well implemented IMO), that AppGameKit will go down the exact same path and will feature a horrible death because of it.

I'm just saying is, let's cut to the chase. Ditch this format before it becomes a nightmare, and stick with a industry-standard format that almost any software app can use. Like FBX. Almost any 3d-modelling software worth it's salt can support it out of the box, so why can't AppGameKit? Why force a proprietary format - possibly broken and feature-devoid - onto it's customers when we can just go with something that's well documented, including it's features and flaws?

I can EASILY see the forums containing posts, "Well why doesn't my model work from MS3D?" Well, the exporter for MS3D is outdated, and was written by XXXX, who was smited from the planet and can no longer update the plugin. It's broken - it get's the angles wrong - you'll have to convert to YYYY and use that app to convert to the format".

EDIT2: The reason why I post all of this, is also because I've seen it with other engines too. TrueVision3D went this exact same route, and the tool they included to convert models into it's own proprietary format either A) failed to run, or B ) failed to do anything productive besides create a file of garbage. And that was their official team developing the tools.

I'm not capable of seeing the future, perhaps this will work out well. I have my doubts, and you know what they say - "the road to hell is paved with good intentions"

Hi there. My name is Dug. I have just met you, and I love you.
Back to top
Profile PM Email Website
MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 18th Jul 2012 11:35
Link
I agree with standards compliance...

Back to top
Profile PM
MarcoBruti
12
Years of Service
User Offline
Joined: 20th Nov 2011
Location: Caput Mundi
Posted: 18th Jul 2012 11:47
Link
I agree too. Pls adopt a standard format, possibly supported by most of 3D Modeling Package, and that's all.
Exporters are already contained in most of 3D sw, so if we start from a standard format, we can switch to another one with little effort, but if we start from proprietary, a bunch of problems will arise.
We cannot rely on spare-time hobbysts or good-will people, TGC must declare if this must be an "open-source", best effort community product, or something serious good to develop commercial games.
In the latter case, I do not see yet enough efforts to make the basic 2D platform as robust as needed by serious indie developer.
If the problem is the money, I shall pay to have more features, 3D standard format, robust IDE and fewer bugs.
Back to top
Profile PM Email Website
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 18th Jul 2012 12:13 Edited at: 18th Jul 2012 12:15
Link
Standards compliance would be handy if there was such a thing as a standard. There is no all-ruling 3D format, .X for example is designed for DirectX. OpenGL doesn't have a distinct format, so it really is a case of setting the standard for AGK.

Personally, I'd be more concerned about animation than anything. If we are talking about just static meshes, then the memblock format would do, or DBO, or .X even. 3D file formats are easy-peasy when there is no animation to worry about. Each vertex needs a position, normal, UVX and UVY, with hopefully support for diffuse colour, and ideally access to extended UV coordinates for multi-texturing. Each polygon just needs a set of vertex indexes. But, animation would involve storing bone assignments, keyframe data, and that gets a lot more complex.

I'd suggest that 2 standard formats are created, one for static meshes, and one for animated meshes. If the static mesh format could be created and manipulated with code, like vertex modifications in DBPro, then I'd be most happy. Imagine making a big segmented mesh for your 2D map, faster than using lots of sprites... then take that to the next level and make a matrix/terrain with code.
We have to keep the data footprint as small as possible, so keyframes and bone assignment are important I think. I mean, it would probably be easier to support say, MD3 models like Quake3, but those end up pretty big, as the model animation is based on interpolating meshes. That kinda limits them at the same time, I'd personally like to be able to do the same on-fly modifications that are possible in DBPro, like offsetting and rotating limbs with code. I think this is important considering that AGK's strength's might still be in 2D, using 2.5D engines with Box2D will be a lot easier if we can check exact bone/limb positions and also affect the angles and offsets. For example, rotating a door limb according to box2D collision response. It might be quite cool to just use the same 2D physics and translate them to a 3D scene.

I guess that's the other factor here, we don't know what shape of physics or collision system we'll have for 3D - makes sense to rely on Box2D if at all possible.

Health, Ammo, and bacon and eggs!
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 18th Jul 2012 12:15
Link
having only 1 format is a good thing.

having this one format in an industry standard format supported by most 3rd party software is a good thing.

having 1 propriety format is not a good thing for us users.
Back to top
Profile PM Email
3d point in space
14
Years of Service
User Offline
Joined: 30th Jun 2009
Location: Idaho
Posted: 18th Jul 2012 12:18
Link
this is what i did 7 years ago in open gl before I went to the military and I think it is still valid. I made most of this project secret. What is this any way this code shows how you can take 2 3ds objects and morph it. Very old code yet still valid.
http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=10053&lngWId=3

Developer of Space Chips, pianobasic, zipzapzoom, and vet pinball apps. Developed the tiled map engine seen on the showcase. Veteran for the military.
Back to top
Profile PM Email Website
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 18th Jul 2012 12:20
Link
vanB: .obj for static meshes and FBX for animations. you can't go wrong with that choice
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 18th Jul 2012 12:24
Link
Quote: "My fear is that TGC will create this format, and then due to customer demand, support another format as well. Thus, we now have two file formats to support in the engine, twice the problems will crop up eventually down the road, and this whole mess was for nothing."


taking into consideration past events, there is a big chance of this happening.

Quote: "This will kill AGK's userbase, because people interested in AppGameKit will notice that it only supports this proprietary file format, and then pass on the toolkit"


i follow other sdks too, and sometimes i wonder if tgc check out what other sdks are offering to users and try to keep up with the competition.
Back to top
Profile PM Email
kamac
13
Years of Service
User Offline
Joined: 30th Nov 2010
Location: Poland
Posted: 18th Jul 2012 12:24
Link
I think there's nothing wrong in TGC making their own format, as long as they allow us to make our own object loaders. (Just give access to vertical buffers, UV coordinates buffers and probably vectors where you store skinning and animation)
This way we will be able to load probably any model not long after the initial 3D release.

Follow me on twitter! @MotionStruct
Motion Struct blog
Back to top
Profile PM Email
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 18th Jul 2012 12:37
Link
Why OBJ though?, why FBX. These aren't industry standards, they are adopted, .OBJ is Wavefront. We might say, why not .3DS - that's more of a standard than OBJ. Of course, there's no reason why it couldn't, or shouldn't be .OBJ - as long as it's a solid standard that supports everything AppGameKit supports... it just depends on what you hope AppGameKit will support.

Diffuse colouring is not supported in OBJ. No precalculated vertex lightmaps no easy terrain shading

The only viable model format that I know of that supports vertex colouring is .X.

I'm not sure about texturing, I mean, can OBJ support more than one texture?

I think we should define our own formats - not only does it let us support the features we want, but also it adds protection to our media.

Health, Ammo, and bacon and eggs!
Back to top
Profile PM Email
Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 18th Jul 2012 13:16 Edited at: 18th Jul 2012 13:24
Link
Why not use this?

COLLADA™ defines an XML-based schema to make it easy to transport 3D assets between applications - enabling diverse 3D authoring and content processing tools to be combined into a production pipeline. The intermediate language provides comprehensive encoding of visual scenes including: geometry, shaders and effects, physics, animation, kinematics, and even multiple version representations of the same asset.COLLADA FX enables leading 3D authoring tools to work effectively together to create shader and effects applications and assets to be authored and packaged using OpenGL® Shading Language, Cg, CgFX, and DirectX® FX.

http://www.khronos.org/collada/

Its already an standard and supported by many modelling tools nativly or thru plugins.

Tgc can have there own internal format but agk outputs collada files of there format when saved or use it when importing.

Android 2.3 Gingerbread , ZTE Skate , 480x800 , 4.3 inches , 800 mhz cpu , 512 mb ram
Android 4.0 Sandwich , Dmtech 3g 9738B , 1024x768 , 9.7 inches , cortex A8 1.2 cpu , 1 gb ram.
Back to top
Profile PM Website
3d point in space
14
Years of Service
User Offline
Joined: 30th Jun 2009
Location: Idaho
Posted: 18th Jul 2012 13:59
Link
I like 3ds the best out of all the options. As long as you keep the data points the same with 3d objects then you can Morph the object from one object to final object. Several programmers already know how to Morph an object any way. 3ds format keeps the data the same in 3d studio as long as you don't delete points.

Developer of Space Chips, pianobasic, zipzapzoom, and vet pinball apps. Developed the tiled map engine seen on the showcase. Veteran for the military.
Back to top
Profile PM Email Website
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 18th Jul 2012 14:45
Link
.obj is very optimized filesize-wise whilst 3ds file are huuuuge
Back to top
Profile PM Email
Jimmanator
13
Years of Service
User Offline
Joined: 12th Nov 2010
Location:
Posted: 18th Jul 2012 16:55
Link
I'd be okay with agk supporting a custom format,
You could Have a program coverts a format like .x then you could export the model the same way you would with dbpro and just run the converter.
Back to top
Profile PM
Airslide
19
Years of Service
User Offline
Joined: 18th Oct 2004
Location: California
Posted: 18th Jul 2012 17:06
Link
I don't think that 3DS would make a difference when it comes to morphing - regardless of the file format, it has to be turned into a plain and simple vertex buffer at some point for OpenGL, and as long as you have access to that, you can do all sorts of fun stuff (by directly manipulating the buffer or with a shader).

The thing that should be remembered is that the in-memory representation of your 3D model could be potentially entirely different than the file format. Ideally, though, to minimize the work done at load time, AGK's proprietary format should map as closely as possible to their in-memory model (but should not do so at the expense of portability, for obvious reasons).

To be honest, I'm somewhat surprised AppGameKit doesn't have an XNA style content pipeline - where content goes through a standardized build process that converts it to whatever is needed for the target platform. Most of the time models, textures etc. can just be converted to a consistent "proprietary" format used by the engine, but the user never sees it. And any assets that need to be in a platform-specific format can be converted to such at build time.
Back to top
Profile PM Email
anwserman
12
Years of Service
User Offline
Joined: 20th May 2011
Location: Wisconsin
Posted: 18th Jul 2012 21:41
Link
Quote: "Why OBJ though?, why FBX. These aren't industry standards, they are adopted, .OBJ is Wavefront. We might say, why not .3DS - that's more of a standard than OBJ. Of course, there's no reason why it couldn't, or shouldn't be .OBJ - as long as it's a solid standard that supports everything AppGameKit supports... it just depends on what you hope AppGameKit will support."


I would argue FBX because.. well, Unity3D is kinda the current leader in rapid-development 3d game software. Having a file-format that is directly compatible with theirs would be an advantage to winning over some of their users.

Hi there. My name is Dug. I have just met you, and I love you.
Back to top
Profile PM Email Website
Digital Awakening
AGK Developer
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 18th Jul 2012 22:00
Link
Quote: "I would argue FBX because.. well, Unity3D is kinda the current leader in rapid-development 3d game software. Having a file-format that is directly compatible with theirs would be an advantage to winning over some of their users."


Good point. The pro version of Unity is very expensive and AppGameKit could be an alternative for those who can't afford it.

After a quick readup on FBX it seems to be widely supported by modeling software which is a big plus. As long as there are no licensing fees involved in using it and there are no better alternatives it seems like a good option.

Follow me on Twitter
Back to top
Profile PM Website
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 18th Jul 2012 22:20
Link
Prediction: in the end we will just get the closed-box format
Back to top
Profile PM Email
anwserman
12
Years of Service
User Offline
Joined: 20th May 2011
Location: Wisconsin
Posted: 18th Jul 2012 23:25 Edited at: 18th Jul 2012 23:34
Link
Well, the main point here is that we brought up some very valid issues to the AppGameKit team, and that's the most important part. For static meshes, I really should care less what format it is in, really - a non deformable teapot should be easy amd trivial to covert from X to Y to Z. It's the more complicated meshes that converters tend to screw up.

However, for animated meshes AppGameKit could use a well known format like FBX. Thus, it would be optimal to support this format regardless, even for simple meshes.

Hi there. My name is Dug. I have just met you, and I love you.
Back to top
Profile PM Email Website
anwserman
12
Years of Service
User Offline
Joined: 20th May 2011
Location: Wisconsin
Posted: 18th Jul 2012 23:42
Link
Thinking about it, perhaps this is TGC's answer to the content pipeline. Perhaps this format is the only way to guarantee rapid "write once deploy everywhere" when AppGameKit goes into 3D. If that is indeed the case, I would say it would be wise for TGC to release the specifications of the file format to the public AND create a utility that coverts major formats to it.

So, .FBX, .X, .OBJ: TGC officially creates and supports a robust converting tool for major formats
File format you made last weekend: here's the specs, goOd luck writing a xonverter

Hi there. My name is Dug. I have just met you, and I love you.
Back to top
Profile PM Email Website
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 19th Jul 2012 00:58
Link
I had a look at FBX and it is well supported, and has a C++ SDK, so I would like to support it in future. But after my first test with an FBX model from an artist resulting in the FBX SDK saying it was a corrupt file, I figured it will probably take a lot longer than I would like to get FBX support stable. Add to this the fact that I couldn't find an ARM/iPhone version of the FBX SDK, nor a spec file for it (is it a closed format?) and it starts to look like a lot of trouble. If you know of a spec for the FBX format please point me to it.

OBJ files for mesh only is easy and AppGameKit already supports these.

Our own format would allow us to load an FBX style format (mesh+texture+bones+animation) on all platforms guaranteed. I'll also happily document it and release as much info as I can about the format to make sure those that want to write exporters can do so. I'm also making the file human readable as I always liked that feature of the .X/.OBJ formats.

I've attached an example file for a simple plane (4 vertices, 2 faces), but I'm still working on it myself. It is a chunked format so any named block that isn't recognised can be skipped meaning it can be forward and backwards compatible (in theory).

It also ties in closely with GLSL shaders so you can support less common vertex attributes such as tangents/binormals/multipleUVs without being required to supply any you don't need in the shader. For example a vertex shader to render the attached plane might be


Then the pixel shader takes normalOut and UVOut to do lighting, texture lookup, etc.

The attributes "position", "normal", and "uv" match the names in the model file and we'll have to standardise the common ones such as these to make custom shaders as shareable as possible.

Let me know if you have any feedback on this.

Attachments

Login to view attachments
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 19th Jul 2012 11:44
Link
I love the "human readable" idea, but .X also has a binary version, and when you saved in that format the data was 60% smaller!
Back to top
Profile PM Email
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 19th Jul 2012 15:41
Link
Quote: "I love the "human readable" idea, but .X also has a binary version, and when you saved in that format the data was 60% smaller!"


I like the idea of a binary version, but it duplicates a lot of work that is not immediately necessary. So I'll hold off on it until I have the time to write a binary importer and a tool to convert between the two.
Back to top
Profile PM Email
3d point in space
14
Years of Service
User Offline
Joined: 30th Jun 2009
Location: Idaho
Posted: 19th Jul 2012 16:01 Edited at: 19th Jul 2012 16:23
Link
Paul wrote
Quote: "OBJ files for mesh only is easy and AppGameKit already supports these. "

If you have obj format already I would stick with it. Add other formats later. If you have not implemented FBX yet, and obj is working fine just use the obj format. The most important thing is that you get 3D out as soon as possible. Most people here just want 3d, obj is fine, for know just can't do a lot with it.

Developer of Space Chips, pianobasic, zipzapzoom, and vet pinball apps. Developed the tiled map engine seen on the showcase. Veteran for the military.
Back to top
Profile PM Email Website
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 19th Jul 2012 16:30
Link
Quote: "If you have obj format already I would stick with it. Add other formats later."


Unfortunately we need a format that supports bone animation for what we want to do with 3D, so whilst OBJ is nice at what it does we also need something else.
Back to top
Profile PM Email
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 19th Jul 2012 16:38
Link
But I think you missed the point, 3D point...

.OBJ is so easy to support, that it's practically redundant. The concern isn't about having nice easy convenient 3D file formats - it's about making sure the 3D engine we end up with supports the vital features. Animation for example - that is the real issue, not having static meshes, static meshes are easy, static meshes could be based on the DBPro memblock format, job done!. Animation is vital, and OBJ does not support animation. It would take 5 minutes for someone to baulk at the 3D support if AppGameKit only supported OBJ, to the point where releasing with just OBJ support is pointless, and detremental.

Anyway, it looks like things are off to a solid start... again, please add in vertex colouring, it would allow people to optimize lighting and take the load off AGK. For example, it's easy to write a vertex colour lightmapper, then disable lighting, so less calculations in the render pipeline. Also, it would be nice to have support for things like vertex colouring on terrains, it reduces the direct need for multi-texturing and can help make terrains really pop, and again it would help with performance.

Health, Ammo, and bacon and eggs!
Back to top
Profile PM Email
erebusman
12
Years of Service
User Offline
Joined: 23rd Jul 2011
Location: Sacramento, CA
Posted: 19th Jul 2012 17:12
Link
Quote: "Why not use this?

COLLADA™ defines an XML-based schema to make it easy to transport 3D assets between applications - enabling diverse 3D authoring and content processing tools to be combined into a production pipeline. The intermediate language provides comprehensive encoding of visual scenes including: geometry, shaders and effects, physics, animation, kinematics, and even multiple version representations of the same asset.COLLADA FX enables leading 3D authoring tools to work effectively together to create shader and effects applications and assets to be authored and packaged using OpenGL® Shading Language, Cg, CgFX, and DirectX® FX.

http://www.khronos.org/collada/

Its already an standard and supported by many modelling tools nativly or thru plugins.

Tgc can have there own internal format but agk outputs collada files of there format when saved or use it when importing."


I was going to suggest COLLADA myself but I see someone else got to it before me.

I've worked with too many products that had only 1 supported format and then no one knew how to create a exporter for it when the next version of Max came out, then it died.

Making your own probably sounds sexy in your echo chamber; from out here is sounds like a recipe for killing your product to me.

I know you don't want to see this but the FIRST thing I thought was "well gee what does Unity support..."

Check if you dare: http://unity3d.com/unity/editor/importing

Thanks!
Back to top
Profile PM Website
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 19th Jul 2012 18:01
Link
Erebusman, I fully agree with you for us users having to work with a propriety format and depend on 1 converter/importer does not bring too much nice prospects.

I hope that AppGameKit 2D will continue to be improved on, fixed and expanded on and not forgotten because of the new 3d version. For me, I think that I will skip on AppGameKit 3D
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 19th Jul 2012 18:04
Link
Cinema 4D format might be another nice option to consider...

http://www.maxon.net/en/support/developer-support.html
Back to top
Profile PM Email
Dar13
15
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 19th Jul 2012 18:19
Link
I think FBX would be too heavy for iPhone/Android according to this link. FBX wasn't meant for realtime rendering it seems, was made more as an intermediary. Perhaps TGC could provide a utility to convert from FBX to the AppGameKit 3D format(or OBJ if it's not animated)?

Follow WTLD's progress on Twitter
Git repository for WasTeLanD
Back to top
Profile PM Email
kamac
13
Years of Service
User Offline
Joined: 30th Nov 2010
Location: Poland
Posted: 19th Jul 2012 18:30
Link
Quote: "For me, I think that I will skip on AppGameKit 3D"


I would like TGC to clear these things out as soon as they can. From what many of you write, you think that AppGameKit will have a separate 3D version, while it's commands should be merged with current AppGameKit version. So, even if you pass on AppGameKit 3D version, next updates which would improve 2D only would still have 3D, meaning you can't get any further updates until you pay for the 3D version.

That's why it would be good to know if TGC goes with a paid 3D update, or is it going to be free and such.

Follow me on twitter! @MotionStruct
Motion Struct blog
Back to top
Profile PM Email
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 19th Jul 2012 18:59
Link
I know <= 0 about 3D formats, but if a new engine is tailored to new things, it may need an updated file format to do the work efficiently on all platforms.

Rather than trying to write plug-ins for each and every editor, it seems to me better to implement specific converters as DLLs for the IDE or the C/C++/Pascal. If the IDE had a pre-and post-build call that could be specified in the project file the way Lazarus allows you to do, it would be easy to scan the data files and offer to convert those that could be converted, and flag an error for those not supported by the converters.

Then, the basic (say .x) object could have additional goodies applied to it after conversion, turning the more primitive file into something better - a bit like putting a Porsche engine into a Nissan Micra.

-- Jim
Back to top
Profile PM Website
3d point in space
14
Years of Service
User Offline
Joined: 30th Jun 2009
Location: Idaho
Posted: 19th Jul 2012 20:41 Edited at: 19th Jul 2012 22:18
Link
you can animate obj format as long as you have offsets and able rotate obj files.
COLLADA is probably more memory intensive then you think. TGC does not want to make another unity clone I think. Unity has tones more programmers then agk has this is why they have so many formats, but one thing agk has that unity doesn't is you can code your game instead of using a gui to code it for you. Unity cost about 4,500 dollars for ios, and android plugins. This cost does not include training. Training cost around 100,000 a year to teach a student how to use it.

Developer of Space Chips, pianobasic, zipzapzoom, and vet pinball apps. Developed the tiled map engine seen on the showcase. Veteran for the military.
Back to top
Profile PM Email Website
Digital Awakening
AGK Developer
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 19th Jul 2012 22:17
Link
Quote: "I know you don't want to see this but the FIRST thing I thought was "well gee what does Unity support...""


Most of the 3D software that Unity supports is through FBX. The other (smaller) formats are COLLADA, .3ds, .obj and .dxf. Basically if TGC want to support a lot of 3D modeling software AppGameKit should use FBX or a converter from FBX to it's own format.

Follow me on Twitter
Back to top
Profile PM Website
3d point in space
14
Years of Service
User Offline
Joined: 30th Jun 2009
Location: Idaho
Posted: 19th Jul 2012 23:03 Edited at: 19th Jul 2012 23:19
Link
if you have small fbx files it be fine, this is why you probly have to use obj with fbx too keep it simple. But if you write every thing in fbx then you probably crash the app. It is like loading too many sprites. The only problems I see is this format is not like db pro. It looks like they intend to make a .x to fbx convertor as well. This discussion is going in circles.

Developer of Space Chips, pianobasic, zipzapzoom, and vet pinball apps. Developed the tiled map engine seen on the showcase. Veteran for the military.
Back to top
Profile PM Email Website
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 19th Jul 2012 23:12
Link
Quote: "From what many of you write, you think that AppGameKit will have a separate 3D version, while it's commands should be merged with current AppGameKit version. So, even if you pass on AppGameKit 3D version, next updates which would improve 2D only would still have 3D, meaning you can't get any further updates until you pay for the 3D version."


If that is the case, then I would like to have this confirmed asap, so that I can make long-term plans
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-05-03 11:53:48
Your offset time is: 2024-05-03 11:53:48