Continued from page 1
JB: The Help Center has full documentation on those functions. There are also groups of SketchUp users who are actively organizing around learning and sharing knowledge about building Dynamic Components.
AFR: The new Dynamic Components allow you to set off behaviors (like color changes, et cetera). Can these behaviors be programmed into rendered-out animations or are they only available when interacting with the model in real-time?
JB: I’m not sure that it is possible yet. Theoretically it is possible. We tend to focus on the real time interaction. That is where SketchUp’s strength lies.
AFR: In terms of speed, does SketchUp 7 now sport multi-processor support for OpenGL? Apparently OpenGL has been multi-threaded on the Mac since OS X 10.4.8.
JB: We look for performance tweaks all across the pipeline. It’s a linear process and one with real limits for us because as we evaluate what is possible with the latest hardware GPUs it becomes a sort of ‘frustrating arms race.’ We know that as we take advantage of more powerful GPUs people will just build bigger models and push up against the limits of the program again. Users only ever care about performance when a program gets slow. They never care about it at all when it is fast.
AFR: What about multi-threading the code base? OpenGL has support for threading in OS X. Can you take advantage or not?
BJ: If you imagine a cube and you are navigating around it the problem is not knowing for sure where the user is going to go next. If you know where the user will go you can split the pipeline and have the next frame started for rendering. We can’t make changes to causality. In a predetermined render or animated render sequence causality doesn’t get violated. In real-time interactive rendering it does.
AFR: That is an excellent way to describe the challenge with interactive rendering. So you can only really optimize the linear pipeline?