Change sky definition without rerunning oconv

1

Hi all

I am using rpict for shadowing studies of a masterplan. For each different sun position, I currently need to regenerate the octree file, which adds a substantial amount of time to the simulation.

Is there a way to avoid rerunning oconv for each different sun position and instead ‘plugging in’ a new gensky definition? Where would this have to be done?

I am using a bash shell on windows.

Many thanks

2

If you build an octree containing everything but the sun & sky using the -f option, then feed this to a subsequent oconv run with the -i option, adding your sun & sky, the incremental build should take very little time. This is the most general way to make small changes to a scene for animation purposes.

3

In addition, if you create a short .rad file calling your frozen octree as an instance, you can then use objview to set up views of the compiled model and may feel more like a normal oconv construction (ie not using -i to include an octree).

All you really need in the text files is as follows:

void instance mymodel 1 octree.oct 0 0

  • “mymodel” is anything (just name for the instance)
  • “octree.oct” is the name and location of your octree without sun & sky definition
  • “0 0” should remain as is unless you need to move rotate the geometry (using standard xform notations)

We also do this when running artificial lighting, so the octrees remain small when running many separate light files.

4

One thing to note about instances: mirror materials don’t reflect direct beams (like the sun) when using them to create mulitple sun-hour studies.

Greg - do you know why this occurs? The material shows up (I think it does) but doesn’t behave as I would normally expect. In our reflection analysis studies, we have to abandon the instance method (or include that geometry separtely. Just adds to disk space and time required to compile each instance.

5

Instancing was added a bit late in the development, and brings along some limitations such as the one you mentioned. Basically, you can’t rely on instanced geometry for light sources, illum’s, or virtual light sources. The code makes a pass on all the loaded geometry, looking for sources and virtual source objects, but doesn’t delve into instanced geometry (octrees or meshes) because there is no good way to index them uniquely.

I don’t quite understand how you are using instances with your light sources, but the emitters themselves won’t behave normally if they are instanced. (You can instance the non-emitting luminaire geometry around it, but not the sources themselves.)

6

Thanks Greg, was just interested in understanding more.

We’re not instancing our light sources, they are saved in a separate “lights” file that is oconv’d with the instance rad file:
oconv mymodel.rad lights.rad > lights.oct
The lights.oct file is quite small, so running many separate light layers does not take up much disk storage or disk write time to create a massive octree on large/complex projects.

7

Thanks a lot, the -i option worked well