Knowledge base and style guide for 3D assets


I noticed that artists willing to contribute to the engine dataset or to the sample game are looking for information about the style and the technical data.

I create that open discussion to centralise all that we know and all that we want about the 3D assets, including :

  • graphical style
  • technical details like number of vertex, supported features, placement, scales…
  • HOW TOs for each modeling app, and integration to the engine
  • assets produced and some screen shots
  • assets to create, concepts, ideas
  • anything usefull !

We will create and feed a wiki page with the most relevent information.

Let’s be creative !


About the assets pipeline having a reference point for :

  • Needed assets : Request / WIP / Done.
  • Assets Idea.
    I dono if there is already existing tool doing that, I personaly can’t found any :confused:
    What i’m talking about is an online assets repository handling the Request/WIP/Done etc… git isn’t that great for that since stuff will get huge pretty fast.
  • Assets Pack could be interesting as starting point but using the jmeSDK i found it not being realy reliable, as it does not allow sharing ressource between project (this should not be our concern) / and not most, it does not allow editing, i mean once a ressource is added to the pack it can’t be edited/removed, you must create a new pack… dono if this is intended.

For an assets production stand point :

  • Concept → Model → Texturing → Animation → impl (VFX)

  • [ → ] stand for being validate point from other dev.

  • Each people contributing could made they own faction so having they own pipeline !?

some idea of way to go, it depends on how the project have to be push forward…

I would add the “skeleting” to the process, for the skeleton is also used to localise many things by the engine : exhaust were to draw smoke, canon muzzle from were projectiles are launched, headlamp for the lighting position… With for each a 3d coord and direction vector.

For the asset repository, I guess any TODO list would make the work. I propose to begin with GitHub issues, by using more wisely the milestones and labels options for now. A milestone for each race perhaps?

When things will grow up, then we could reconsider.

I’ve made two milestone on the github issue system. I suggest we add an issue with the corresponding milestone for each needed asset, beginning with a concept art or a valuable idea of design.

Maybe could help with organizing tasks and todo?

Might as well use something that integrates with GitHub issues then, so things don’t get too spread. There’s a whole bunch of Kanban board apps that do this: (doesn’t appear to have a “free for public repos” plan)

The point about asset is more about having access to them than about getting track of them, using the gitHub base system we can get track of them without much effort, but it didn’t resolve the access issue as it make people having to upload they work on they own, this making it unrealiable as exemple :
Step 1 - I work on a new unit, i make all the design, upload and submit them under a new github issue.
Step 2 - Life run at me and i’m unable to go further, during that time the tool/site/server where i’ve uploaded the design got shutdown…
Step 3 - The next guys/girl coming after me, even if the issue is still there can’t expand from the initial work since he/she don’t have access to it, this make him have to start again from Step 1.

As far as i know Git isn’t mean to upload 3D art, image or stuff, as it will get huge very fast. A versionning system is nice for programing but not that much for Art as every artist always have copy of they work made manualy while working, not to mention that they always send the latest work as when it is done or nearly done…
Another tool is required to resolve this, something allowing us to have every asset on one point, a place we can upload and download asset individualy.

1 Like

…said so many software developers at one time or another “I don’t need version control because I just keep 50 copies of everything locally…”

Git is horrible for binaries but that doesn’t mean you shouldn’t be using version control for assets. Real game dev companies definitely do.
Alternativly svn has no problem with large files (but a few other problems :slight_smile: )

Yeah, SVN was quite nice for binaries. GIT has two things against it here… one is that it just doesn’t deal with them well, the other is that every cloner must get all versions of the binary (further compounding the other issue). So much fun to clone a repo and find that some bozo has checked in 100 meg of binaries that I must now download. :-/

I wonder how that extension deals with that problem as it’s sort of the ‘nature’ of git that you get the full repo (I call it a huge downside, others call it an upside… either way it’s a feature.)

Kill that guy!

I would LOVE to worry about a messy repository full of assets, with hundreds of versions to deal with, and have to find a solution.


@pspeed Don’t get me wrong if there where a versionning control out there to handle art stuff i’ll be the first one to use it, and wouldn’t be the only one to do so. But, on the current stage they aren’t any, all versionning system i known currently take too much space if wanting to store art.

Alternativly svn has no problem with large files (but a few other problems )

I’ve saw this but still in beta, have to wait a bit to try it out :smiley: could be pretty nice.

I use SVN for art assets and it’s fine. It diffs even binaries so it’s more efficient than simply storing the binary n times as it only stores what’s changed. Still not as efficient as something that would understand the binary but those systems usually cost a lot.

Plus, I find my binaries are generally smaller if I’m not keeping 100 layers or hidden objects around “just in case” I need to see them again. But maybe that’s just me.

1 Like

Could you explain why it is important to have a powerful versionning system for art stuffs? is it so frequent need to open an older version?

Sorry if my question is naive ^^

I would guess its the same reason as in programming. Beeing able to always rollback to a working version :wink: Without having to care.

At least i would more freely draw a line on a texture if i know i can always undo it


Every time you catch yourself leaving a layer in photoshop “just in case I need it later” or peppering your driver with mytexture1, mytexture2, mytexture3… you are manually implementing a version control system. Embrace the freedom of being able to check out your whole project at any point in time.

“Wasn’t this part of the level brighter 6 months ago? Did the engine change or is it a graphics change?” Checkout the project from 6 months ago and see.