(updated with more details on developer files)
Hi folks!
Months passed again, but this so called projects is still alive here!
It’s something I’m slowly updating while doing real production at our studio, but I’m now at a point where I can say that we have some pipeline of sort at last!
All this stuff is done thanks to the community! In particular I bothered a lot @bob.w, @Theodox,@instinct-vfx, @Dhruv_Govil, and @Minkiu, the last 3 in particular for Rez and add-on management!
Many thanks to all of you!! But also to all the people that give me hints and ideas on Slack and I can’t mention here because of…memory
Project Folder Structure
I fought my personal battle with associates programmers trying to convince them to use some sort of standard structure for projects and in the end we found a common point and an agreement on this.
Now a standard UE4 project here is
Main folder: *ProjectName*
|
|--Engine (if we use a custom compiled version of the engine, it will stay here)
|
|--GameProject (conainsi the Unreal project, so the COntent, and all the C++ game source code)
| |
| |-- Content
| |
| |-- ProjectName
| |
| |--Core
| |--Level Sequences
| |--Maps
| |--*All assets folders*
|
|--Raw (production and intermediate assets files)
|
|--Developers (like UE4 calls it, personal testing files, untested stuff and so on)
| |--developername (a folder for each dev)
|
|--Work (source files like .blend, .MAX, .psd, ecc)
|
|--Import (files to be imported in engine like .fbx, .wav, .png, .tga, ecc)
Assets folders
The folder structure under Work and Import is the same and given some rules is project specific. But it has to be the same so our Export/Import scripts can easily save files into the correct place.
Speaking about assets, the Content\ProjectName too share the same subfolder tree.
So the idea is that once it’s decided where an asset must go, we just create its source file (like a blender scene) in the proper place under Work. The exporter automatically writes the fbx in the same position but under Import… and the same subtree will be recreated under the Content\ProjectName folder by the engine importer.
The same applies for Developer files: only difference is that they ends in specific subfolders of Conten\Developers.
We’ve lost some minor advantages to me in not keeping source and intermediate files together… and speaking of UE4, without having the fbxs near the correspondent uasset, but I greatly prefer this clear organization.
The downside is that if an asset must change folder for some reason, we have to change it up to 3 times.
Internal tools
At the moment we model with Blender and use UE4.
So I wrote:
- a Blender exporter (see dcc-kit critique post about this, if you want to). It’s based on an agreed-with-artists scene hierarchy to organize the assets and control how they’ll be exported, with what name and where.
- an Unreal importer: this allows artist to import single files, folders or folder trees inside the engine. By default it tries to mirror the folder structure and recreate it under the Content, instead of relying on artist’s (an me) care with folder names. It also automatically import developer assets in the proper place.
- an Open source file for UE. This works in combination with the Blender exporter, that writes some metadata inside the FBXs. This small tool (not fully tested yet) opens the source .blend of an uasset directly from UE. Quite nice if you have to edit a mesh and to avoid picking the wrong file.
For now is going fine: of course all of this is in a very early stage…
Managing all tools: the Rez way
In the end, after a lot of tests, I went for the Rez way.
I tried both bleeding-rez and vanilla rez, deciding for the latter in the end.
I think that the tool is great but it has a quite steep learning curve for people like me that are really new to that kind of environment management world. For the records, some more introductory docs will be really helpful to spread the tool
A problem here at our studio is that since we don’t force too much sw on machines, users could have any Python version installed, added to Path or not.
And it’s true that rez could resolve a Python package to use in an environment, but it still need a Python to work.
This was my biggest problem.
I wanted something portable-like, a standalone rez of sort.
Possible?
I found a rough solution with WinPython.
The idea is this:
- We agree on a unit letter to be used four our tools… and it’s *T:* (oh, we’re on Windows!)
- I remap a local tool folder to T: with subst command
- I unzip WinPython 3.7.4 in that folder and use that interpreter to execute the rez setup (under that mapped unit again).
Doing this, all rez stuff will be permanently bound to that unit and that portable Python interpreter.
Packages folders (local and released) are set in a rezconfig.py file and it’s location added yo user’s env vars.
At this point it’s possible to copy/paste this folder to any machine, any folder… map this folder as T:, set the env key for the rezconfig file and it’s done. Without install and without worrying about system Pythons.
All packages will reside on a remote folder and not on user’s machine: users only have the Python,arc,os,platform packages.
I wrote a script called redrez (redistributable rez) that basically does this whole setup on a new machine, given some destination folders.
It’s still an ongoing process, as I said, but I’m now seeing something working and it’s already a small victory!