How do you organise your Radiance model files?

radiance-general
1

As I have been working on my living room exercise, I have been dividing up the 3D models and their associated .hdr textures, .mat files, and .cal files in a way that I can reuse again in other projects. I would like to share these with the community, but in order to best share, I would like to organise it in the best way for others. If I just sent a bunch of files, it may not be easy to reuse.

Here is an example of a typical project, with one reusable asset I have called cool_chair:

lib/ # dir to hold all scene assets
lib/cool_chair/ # holds a single asset
lib/cool_chair/obj/ # holds all "objects", e.g. rtm, obj, oct, or source files such as blend files
lib/cool_chair/obj/cool_chair.blend # the source file, if anybody wants to tweak
lib/cool_chair/obj/cool_chair.obj # the baked geometry
lib/cool_chair/obj/cool_chair.rad # radiance mesh primitive, in this case
lib/cool_chair/tex/ # holds all hdr texture files if any
lib/cool_chair/tex/leather.hdr # an example texture
lib/cool_chair/cal/ # holds all cal files if any
lib/cool_chair/ies/ # holds all ies files if any
lib/cool_chair/mat/ # holds one or more mat files for the object
lib/cool_chair/mat/cool_chair.mat # material file
lib/cool_chair/Makefile # provides "make lib" which builds necessary rtm, oct, or whatever files so we don't check these into version control
lib/cool_chair/README.md # asset readme file
lib/cool_chair/LICENSE # asset license file
README.md # project description
Makefile # will provide "make render", which will build everything and start rendering
scene.rif # rad input
scene.rad # this is the main scene file, everything is linked from here
LICENSE # project license file

If I wanted to use cool_chair in my project, I would copy it into my lib/ dir as shown above, and then add add to scene.rad:

!xform lib/cool_chair/obj/cool_chair.rad

In this case, we have used the OOTB obj file provided by the asset in lib/cool_chair/obj/cool_chair.obj. It is possible to customise or re-export the asset object files, or whatever if you need. If cool_chair comes in different shades of leather, its Makefile could build things diferently depending on multiple material files in its mat/ directory. If the asset is a particle which needs generation (e.g. grass / leaves / bricks), its Makefile can allow for that by allowing you to generate your own object in its obj/ directory.

This organisation method isolates each asset into its own directory in the lib/ folder. That directory can be copy and pasted verbatim to another project’s lib/ folder and it will retain all licensing information, original geometry source files, material files, and so on. It can be loaded it as a git submodule. You can create branches for modifications.

I find this workflow seems to scale when you have many complex objects in the scene, as it is is grouped primarily by object, not filetype. It also means that without even rendering, anybody looking at the project knows what’s in my scene.

As for the naming of cool_chair itself, I am currently unsure of the best approach, but I am researching building classification systems and integration with things like IFC, OmniClass, Uniformat, etc, as most Radiance assets I assume would be building object or building entourage.

I would be happy to share my assets in this structure, but would like community feedback and to know what other workflows you’ve developed to know how I can best share assets.

1 Like
2

I have a suspicion that your living room example is pushing you to think harder about scene organization than many other users, but I’m certainly curious to see if anyone does have suggestions for how they handle such things or for sharing around the community.

There are probably many users getting scene content from comprehensive 3D models (Revit, Rhino, Sketchup, etc.) where the furniture and any other objects are embedded with the exported/imported scene geometry produced by others or larger teams. And many users might not be using textures and .cal files for typical daily work - maybe instead representing approximations using plastic, glass, and metal material definitions for typical simulations.

1 Like
3

Thanks @Christopher_Rush, it would be good to see how others are dealing with this.

I’m sure that users are getting scene content from other means. Geometry comes from everywhere, and this isn’t an issue, usually. You are also correct that most users probably don’t use textures or cal files. This is a pity, because that’s where the fun is (for me, at least)! :slight_smile: That’s OK - they can simply exclude the cal/ and tex/ directories if they don’t need it.

I have rewritten the file organisation structure here:

https://thinkmoult.com/proposed-radiance-filesystem-hierarchy-standard.html

And I have just released the first of hopefully many to come 3D models for free online under open source CC-BY-SA. You may recognise the book :wink: It was also used in my living room render on top of the desk.

https://thinkmoult.com/book-rendering-with-radiance-free-3d-model.html

book-rendering-with-radiance

I have started a git repository browser here if you’d like to peek at the sources. It runs a git lfs server, so large binary assets can be versioned :slight_smile:

http://git.sevenstrokes.net/

1 Like