Re: Best practices for OpenSCAD + Blender
Great
Thanks
Please share a video tutorial of your approach.
That would make things more clear
On Tue, 25 Oct, 2022, 1:07 am neri-engineering via Discuss, <
discuss@lists.openscad.org> wrote:
---------- Forwarded message ----------
From: neri-engineering neri-engineering@protonmail.com
To: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org
Cc:
Bcc:
Date: Mon, 24 Oct 2022 19:32:40 +0000
Subject: [OpenSCAD] Re: Best practices for OpenSCAD + Blender
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 https://proton.me/ 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 https://proton.me/ 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.
---------- Forwarded message ----------
From: neri-engineering via Discuss discuss@lists.openscad.org
To: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org
Cc: neri-engineering neri-engineering@protonmail.com
Bcc:
Date: Mon, 24 Oct 2022 19:32:40 +0000
Subject: [OpenSCAD] Re: Best practices for OpenSCAD + Blender
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org