![[ca]](/mwf/flags/ca.png "Canada")
I have written a (work-in-progress) Artist's Guide which covers how to export 3D models for OpenClonk and actually have them work in game.I hereby license the following file(s) under the CC-by license
Attachment: OpenClonk-ArtistsGuide.pdf (1007k)
![[de]](/mwf/flags/de.png "Germany")
Wow cool. I just talked with pluto the other day that any form of documentation, not only for scripts and code, is vital. However, the information you wrote should definitely go into the wiki. Namely in to the artists guide. Currently the artists guide is very much written in a tone like "if you wanna help the project,..." which should probably go more into the direction of a general documentiation in the future.
Why it is not a guide who to use this strange rig, mesh, etc of the OC-Clonk :(
But fine, if I succeed this "mission" i hopefully can add other graphics, so thanks to ya for the knowledge what is to do that it will work :>
But fine, if I succeed this "mission" i hopefully can add other graphics, so thanks to ya for the knowledge what is to do that it will work :>
All information contained within this guide has been added to the wiki, so this pdf is now officialy obsolete. Yay!
A lot of restrictions ...
- Only one model format supported
- Too much to regard (no flat, no transformations)
This could be an obstacle for modders to make their own packs and I think, 2D graphics will be too "outfashioned" to use them as an alternative.
Maybe a fixed Blender exporting script could fix that? (Adds the 3D-making vertex, applies mesh transformations to both bones and vertices)
- Only one model format supported
- Too much to regard (no flat, no transformations)
This could be an obstacle for modders to make their own packs and I think, 2D graphics will be too "outfashioned" to use them as an alternative.
Maybe a fixed Blender exporting script could fix that? (Adds the 3D-making vertex, applies mesh transformations to both bones and vertices)
Well, I don't find it a lot of restrictions. Making models for games has some natural restrictions, like polygone size and so on.And it is better in my opinion, to be aware that you can't use modifiers on meshes than that they are magically somehow applied (which can cause a lot of unknown stuff I you don't know about it).
As for only one model format. Blender is a good free modelprogramm, so should be available for everyone. If someone wants to use another format, there might be an exorter too which he can use and then write his experiences in the wiki.
>which can cause a lot of unknown stuff I you don't know about it
what exactly?
in gwX, you can have transformations in the model, external transformations (via model encapsulation) and nothing that could cause "unknown stuff" - (with a clear math based rendering architecture of course [maybe you forgot to renormalize the normals after scaling?])
There are other model formats with better exporting support. If you have a generic model interface, it should be no problem to introduce more than one model format.
>- Only one model format supported
I'm not sure I see this as a downside. A single format will stop confusion since their is only one method for exporting; the user will not need to know 10 different ways to get models working in game.
>- Too much to regard (no flat, no transformations)
I don't think transformations can be considered a restriction either, since you can build a model without using any transformations from the start (instead of making a transformation to the object, go into edit mode and do the same thing to all vertices that you would have done to the object).
> - Only one model format supported
we're writing a game here, not a 3D modeling program
> - Only one model format supported
Apart from the stuff already said: Remember an additional model format wouldn't just need to be implemented, but also needs to be maintained. As new features are introduced or internals are changed, both importers need to be made aware of it.
The problem is similar to that of e.g. the multi-platform support (Win32/64/Linux/MacOS). In theory, the platform-specific code is neatly tucked away in their libraries and rarely needs to be touched. In practice, you need to work on it and extend it all the time; things behave subtly different for different implementations and cause bugs; etc.
Whenever a port does not have an active developer maintaining it (as was often the case with the Mac port), it tends to degrade over time and need work to get it running again. The same would happen with another model format if it were not actively used.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
