The radiosity data I guess can be ignored or be used for comparison.
In any case with the above data in theory I have all the needed information for applying a light simulation with Radiance, i.e. 3D model, vertices, faces, normals, reflectance and the vertices corresponding to the 6 light sources in the scene thus, their position from where possibly I could apply a light source model by using an IES file or something. My question now is the following, would be easy for someone to give me some details how I could use these data to model radiance and irradiance through the Radiance light simulation tools so that to get the corresponding flux/lux values.
Also does Radiance supports an output in the 3D space meaning per vertex/face.
I haven’t used Radiance before, thus I would appreciate any feedback about how to deal with such data or even how to restructure it for being possible to apply such a light simulation with Radiance.
As far as I know, there are no general material converters for Radiance. Most people redefine the materials and assign them to surfaces based on material IDs. The obj2rad program has a complicated means of mapping materials to surfaces, but you can usually just use the assigned material name.
Well, you have the material NAME assignments, but not the actual materials. You have to create those in a text editor or assign them from a library of materials. Either way, you need to know/learn enough about Radiance to define your materials based on what the objects are supposed to look like. The information in your *.mtl file may offer some clues, but they won’t translate directly.
I see, what is the proper way to create these materials. I guess there should be some automatic way or something, right? I cannot imagine that this has to be done manually.
Imagine that I have hundreds of such rooms. There should be a way to automatize this procedure.
I’ve found this thread where a similar discussion was up. According to @Terrance_McMinn1 I could create my materials by porting them from the .mtl files but what it is not clear to me how the r, g and b can be extracted from the variables Ka, Kd and Ks since each one of them has their own correspondences. Is it fine to use only the values from Ka. Also how do I define the values of specularity and roughness.
That other thread is a decent guide. You’re kind of on your own with translating the non-physical model of Wavefront to the physical materials in Radiance. The specularity is related to the Ks and the color the the Kd, generally speaking. You can look into the Radiance material models here. The only other formula I can offer is an approximate conversion from specular power to roughness, which is:
Hi @Greg_Ward many thanks for the references and the short of explanation, appreciated. I’ve also found another old thread where you are also explaining a short of pipeline to be used. I will try to create a kind of Wavefront2Radiance translator and possibly share it here. Just to clarify for the color is it the values from Kd or Ka that I should be using because above you mention Kd but in your older message you say Ka and Terrance also refers to Ka to be used for color.
@Greg_Ward I am trying to parse my Wavefront .mtl file for creating a .rad corresponding based on our discussion above. However, if I look on my file I have materials which they do not contain a Ka parameter but only Kd, e.g.
In that case I guess I can use Kd instead of Ka, could you please confirm.
Moreover, in material m37 I have the parameters Tf and Tr/d which correspond to the transmission filter and transparency/opacity/dissolve of the current material respectively but based on this guide I am not sure where to address it. Should be a dielectric material? I would appreciate if you could give an example, if possible.
As Greg mentioned, the wavefront materials do not follow a physical model.
So much of how to interpret the different parameters to radiance materials
depends on what assumptions were made when creating the wavefront obj:
Whether Ka or Kd maps to the color of a radiance material (and for that
matter whether to use a plastic or metal) really depends on the export and
how the values were selected in the source program.
settings, the materials could match either the layer color, layer material,
object color or object material.
Furthermore, depending on the means of assigning those materials, how
specularity and such are assigned can also vary. Whether the values in the
mtl even have physically descriptive information, whether the colors need
gamma correction or not, and whether the parameters can even describe a
physically possible material (which radiance more or less requires) depends
entirely on where the values are coming from, which you have not described.
From a quick glance at your included snippet, by a
conventional interpretation of the wavefront spec, these are not physically
possible materials (specular reflections are way too high, total reflection
and transmission exceeds 1, Ka usually corresponds to an ambient light
(self luminous surface) etc. With these materials, any calculated physical
quantity (like illuminance) would be meaningless.
If in spite of those warnings you want to write a mtl to radiance
interpreter (always keep this in mind: https://xkcd.com/1319/), I would
suggest getting a firm handle on the wavefront material specification,
start here: https://en.wikipedia.org/wiki/Wavefront_.obj_file#Basic_materials and then
check the references. After that familiarize yourself with how the program
you are using maps its native materials to the wavefront obj (paying
attention to physics and what colorspace the native renderer operates in).
And then make decisions about what properties are important for your model
translation (colored highlights, index of refraction etc.) Finally, spend
some time understanding the radiance material primitives ( https://floyd.lbl.gov/radiance/refer/ray.html#Materials) and pick out the
subset of materials to map too (my guess is you can use plastic, glass, and
trans).
During this step you may decide it will be easier to write a material file
(or translator) directly from your native format to radiance, bypassing the
mtl file altogether, except to gather the names (as Greg assumed you were
doing). To address the issue with thousands of rooms, it is unlikely that
means you have thousands of different materials (and if you do, how were
they defined?), you can take two paths, either simplify the naming in the
native model, or make use of the alias descriptor (see: https://floyd.lbl.gov/radiance/refer/ray.html#Scene and search these
archives), it should be straightforward enough to automate the generation
of thousands of aliases that point to the handful of user defined materials.
Hi Stephen, thanks a lot for the thorough feedback. Well from your description it seems that even if I manage to translate the wavefront materials to radiance ones it would be like shooting in the dark without any warranty that my output would be 100% accurate.
The tools that I am using to extract the scene can be found here this translates the json file from my attached model on my second message to the .obj and .mtl files of my scene. From what I understand the material mapping to the .mtl is done during the reading of the scene since my room layouts and included objects are already predefined. Thus, I guess translating the .mtl files to .rad is my only option.
The point is that going with such kind of models is my only option for now since I cannot find any other large scale dataset with multiple rooms and objects that would follow a physical model. If you are aware of anything that I could use I would be happy if you could share some info. I’ve opened a corresponding thread here but so far there is no response.
@stephanwaz the other case scenario, which for now it might be fine for my needs is to consider a fully lambertian environment. In that case, Kd value from the wavefront .mtl files should be sufficient.
but then when I give obj2rad -m materials.rad house_room2.obj > house_room2.rtm it doesn’t really seem to do anything. My .rtm file gives something like:
Ok, I thought that obj2rad was the one I should use again. I will test it tomorrow.
Regarding texture mapping as I understood you suggest to use Lu/Lv instead of frac(Lu)/frac(Lv), right? what is their difference, there is also tile_u/tile_v? Because I’ve already went over some previous threads but I did not really understood when I should use each.