Re: Best practices for OpenSCAD + Blender
I haven't looked at it in many years, but you might also look at
POV-Ray, which is a script-style modeling tool intended for creating
photorealistic images.
In this case I'm really looking for best practices to "join" the outputs of OpenSCAD up with Blender.
Sent with Proton Mail secure email.
------- Original Message -------
On Friday, October 14th, 2022 at 9:18 PM, Jordan Brown openscad@jordan.maileater.net wrote:
I haven't looked at it in many years, but you might also look at POV-Ray, which is a script-style modeling tool intended for creating photorealistic images.
Actually I'm looking into povray now.
Thanks.
Blender has a fairly complex .blend file format, which various tools can analyze or even construct, e.g. there is a Python module called bpy. But still, Blender is a bit overboard in its complexity if you just want to do something simple. I'm sure it can handle all the cases but the learning curve must be steep, because having the .blend file is really the "entry point" into calling Blender command-line, and programmatically constructing the .blend file is, well, there's a rather steep learning curve.
A slightly simpler tool such as povray which is designed to be used command-line may be a good alternative in many situations.
I'm looking into that and other alternatives at the moment, in order to avoid having to analyze/construct the .blend file.
Thanks for the suggestion.
Sent with Proton Mail secure email.
------- Original Message -------
On Friday, October 14th, 2022 at 9:18 PM, Jordan Brown openscad@jordan.maileater.net wrote:
I haven't looked at it in many years, but you might also look at POV-Ray, which is a script-style modeling tool intended for creating photorealistic images.
I'm making huge progress into "discovering" how to couple advanced rendering tools (e.g. Blender or POV-Ray) with CAD software such as OpenSCAD.
At some point I'd like to make an online tutorial on this subject, consisting of webpages, images, and animations, but currently I don't have my servers colocated at the data center (so no ability to make webpages at the moment). Also I'm busy trying to make money to buy food etc.
I will just mention these ideas in a nutshell in this email.
I will omit any discussion of texture mapping UV-map stuff for now (e.g. labels and decals) because that's a whole different cup of tea, and the solutions for that are varied and intricate. Obviously OpenSCAD has no notion of a UV-map, and rightfully so. I guess I could just state that a decal can be rendered as a separate physical 3D object, which is lifted off the surface of CAD model by just a hair.
So background, I already have rather advanced animations (assembly videos) that are generated entirely in OpenSCAD, modulo image processing with GIMP and/or FFMpeg after the fact. The animation movements and part introductions are already modeled in OpenSCAD, as 't' goes from 0 to 1. Camera movements are computed in the calling shell script (#!/bin/sh), using smooth cosine interpolated functions etc.
So the question arose, how could I "render" my complete animation in another tool? I will answer that question here but only very briefly (again, I'd like to make an online tutorial with a very simple screw/nut example at some point, or maybe a rolling ball bearing with ceramic races and steel balls).
Well, here's how I thought I would do it. At every animation frame, meaning, at a fixed value of 't', the OpenSCAD software renders the entire scene in preview mode, at a certain camera angle determined by the calling shell script. Instead of rending that frame to PNG file, we could instead build a directory of STL files for that frame alone. On each frame, we could call OpenSCAD multiple times, each time requiring it to generate and save the STL corresponding to only a single part. The desired part could be passed into the OpenSCAD command-line call with one of those "-D" flags. After multiple OpenSCAD calls for that single animation frame, a directory would be filled up with clearly labeled files, one file per part that is in the animation. The name of the STL files would presumably indicate which part corresponds to the file.
On the renderer side of things, it would now be easy to distinguish between parts. We would not need to separate parts in a massive STL file, because the parts would already be separated into separate files. The renderer could "know" which texture etc. to apply to the piece based on which file it came from, the name of the file could "map into" a parts database of sorts, which would have information about the material of that part. Is it plastic? Is it metallic and shiny? Etc.
That would be the organization of how to pass the animation scene elements from OpenSCAD to an animation tool. The great thing about this sort of approach is that the animation offsets, distances, speed of moving parts, etc., would all be done in OpenSCAD, and this is ideal because the CAD tool itself has inherent knowledge of how things move around - the computation of parts is highly correlated to the parts in motion and interaction with other parts. For example, a screw has a pitch for the thread, which defines how much translation is caused by one full rotation of screw. Ball bearing animations etc. are similar. The OpenSCAD tool is THE BEST PLACE to animate all of these intricate things, and THE WRONG APPROACH is to animate these things in a rendering tool, in my opinion. The only thing that makes sense to "animate" in a renderer is the camera, in my opinion, and/or lighting. So the problem really boils down to how to pass the individual solid pieces to the renderer, so that it can figure out how each of the pieces "looks". But, the pieces as they are passed to the renderer also contain the exact position of the piece during the animation - translation, rotation, etc.
By the way I'm sticking with POV-Ray. Thanks for the suggestion. It is a tool that is inherently designed from the ground up with scripting in mind, unlike Blender for example. It really is a perfect fit for going from an OpenSCAD animation to a photo-realistic animation. Plus, it offers way more possibilities than does Blender, simply because it's a ray tracer.
Sent with Proton Mail secure email.
------- Original Message -------
On Friday, October 21st, 2022 at 12:59 AM, neri-engineering neri-engineering@protonmail.com wrote:
Actually I'm looking into povray now.
Thanks.
Blender has a fairly complex .blend file format, which various tools can analyze or even construct, e.g. there is a Python module called bpy. But still, Blender is a bit overboard in its complexity if you just want to do something simple. I'm sure it can handle all the cases but the learning curve must be steep, because having the .blend file is really the "entry point" into calling Blender command-line, and programmatically constructing the .blend file is, well, there's a rather steep learning curve.
A slightly simpler tool such as povray which is designed to be used command-line may be a good alternative in many situations.
I'm looking into that and other alternatives at the moment, in order to avoid having to analyze/construct the .blend file.
Thanks for the suggestion.
Sent with Proton Mail secure email.
------- Original Message -------
On Friday, October 14th, 2022 at 9:18 PM, Jordan Brown openscad@jordan.maileater.net wrote:
I haven't looked at it in many years, but you might also look at POV-Ray, which is a script-style modeling tool intended for creating photorealistic images.