A google search "STL VR" seems to turn up stuff.  You could also search in
duckduckgo.  Keep in mind OpenSCAD can export files to formats other than
STL (and it is possible that some of those are easier to import into some
VR viewer)

https://www.youtube.com/watch?v=u9qqDqS3Wjk

On Sat, Jan 1, 2022 at 8:14 PM Jordan Brown openscad@jordan.maileater.net
wrote:

On 02.01.22 02:14, Jordan Brown wrote:

Not actually VR, but I suppose
https://github.com/openscad/openscad/pull/3693
is near enough in operation that it should allow VR support
feature wise.

Not happening ever with the official SDK which seems to be
Windows only and as far as a quick glance at the license
shows also very much incompatible with Open Source software.

How would that work? Typing on a virtual keyboard?

ciao,
Torsten.

On 1/1/2022 5:29 PM, Torsten Paul wrote:

Not quite what I was thinking of, for that question.  For that question,
what I was looking for was a way to take a model created in OpenSCAD and
move it over to a VR environment like AltspaceVR.  (Which, I think,
means moving it into Unity.)  I suspect this would likely involve
translating it to glTF https://en.wikipedia.org/wiki/GlTF.  There
would likely be other steps along the way, to do things like add in
colors and textures.

Quite possibly, OpenSCAD's color/texture limitations would make such a
translation be ... unsatisfying.  You might have to import the model
into some other tool and interactively add the colors and textures, and
of course you'd have to repeat that process every time you changed the
model.

But the binocular-vision stuff might well tie into some of the questions
below about previewing into VR.

Are you thinking of this paragraph?

1.2.8 use or redistribute the SDK or any portion thereof in any
manner that would cause the SDK (or any portion thereof) or Oculus
to become subject to the terms of any open source license or other
restrictions.

But is that really different from any other case where an open-source
program is compiled against proprietary headers or linked against
proprietary libraries?

The open-source aspects seem totally tame.  I don't immediately see
anything that would stop you from giving away the sources to your Oculus
program.  Of course, those sources would only be useful to somebody who
has the Oculus SDK, but your sources could be totally open.  The more
interesting question is whether the binary distribution could include
components compiled against Oculus headers, or could include Oculus
libraries.

There appear to be a fair number of VR projects with "Open" in their
names, including some with ties to Oculus.  For instance, there's
OpenXR:  https://developer.oculus.com/documentation/native/pc/dg-openxr/
.  Now, what that really means and how it interacts with other
open-source licenses... tough to tell.

Yes, and viewing the source on a virtual display.

That part probably already works, if I could get the remote-desktop
stuff working.  I could probably run OpenSCAD on a virtual desktop in
VR... but then the model would still be flat, on the virtual screen. 
The trick would be to (somehow, waving hands furiously) pull the preview
away from the virtual desktop and have it render into the VR space.

On 02.01.22 03:17, Jordan Brown wrote:

Different? No. It just makes it useless for Open Source and
impossible to use with OpenSCAD.

There's other things like "no extraction of source code" which
is sort-of the point of Open Source.

I think that is crystal clear. Your license grant is revoked
doing that. So redistribution of that application is violating
law.

I think I remember reading some stuff from Khronos about
some cross platform / cross devices API for VR. That might
be an option at some point. But considering how all those
devices tends to end up in walled (Windows) gardens, I'm not
holding my breath.

ciao,
Torsten.

On 1/1/2022 6:41 PM, Torsten Paul wrote:

There are plenty of Open Source projects that are dependent on
closed-source, proprietary components.  On Windows, OpenSCAD itself
depends on GDI*.DLL, I'm sure, and it's closed-source and proprietary.

The questions are all around how those components get onto the user's
system.  Sometimes they come with the system (as for GDI*.DLL, and libc
on any proprietary UNIX).  Sometimes they come in wads supplied by the
vendor (as for the Visual Studio redistributables).  Sometimes they are
bundled more tightly with the application.

The Oculus SDK license that I'm looking at seems to specifically allow
redistributing their libraries with your application.  Of course that
doesn't mean that the terms (e.g. no source) will be ones that you're
happy with, and it might conflict with other licenses that you have on
your application.

But requiring a closed-source component doesn't seem like an instant killer.

That's the OpenXR stuff.  And yes, it's far from clear how it will all
play out.

The devil is in the details, of course, but Oculus doesn't seem totally
averse to the idea of open source.

https://developer.oculus.com/blog/open-source-release-of-rift-dk2/

The Quest runs Android under the covers, so they have to be at least
somewhat FOSS-friendly lest their infrastructure development dry up.

But I really wasn't interested in a legal debate over whether the
licensing can work, but rather wanted to know what people had done in
this area.

I'd kinda like to join a mailing list on just this topic...

Thus Jordan Brown hast written on Sun, Jan 02, 2022 at 01:14:06AM +0000, and, according to prophecy, it shall come to pass that:

I currently use Gravity Sketch (free!)  on my Quest1.
You have to create an online account and upload your files there, then your
headset will download the files.  Keep an eye on the size.  (Skimming an
article, it says you can upload files directly to the directory that
contains the "example files (Hand, Motor & shoe_last)"  Files need to be
OBJs.  I typically use the opensource Meshlab or Blender to convert my
STLs to OBJs, but there are other tools.  The files I imported started life
as STLs from HeroForge and they did not have textures (*colors applied
directly to the models) or .MTLs associated with them, so my imports had no
color and were grey.

On a friend's headset, I think we used Tilt Brush ($20) to import STL 3d
scan of me and one of him.  These had no texture either.

I've done most of these pieces, but haven't gone all the way myself.

Note:  My environment is Linux.

You should be able to do it with a toolpath of:

• OpenSCAD  -->  STL
• STL  -->  Blender --> OBJ and PNG(texture) and MTL
• PNG  -->  Gimp  -->  colored PNG  (this is the colored texture)
• OBJ/PNG/MTL  -->  Unity3d  -->  some-kind-of-executable
• executable  -->  SideQuest -->  Quest2

There's other tools you can use for various things.

I use (an older version of) Blender to simplify the meshes then create and
export a UV map.  This is a PNG that has the outline of every
face/side/polygon of the model.  Then I export the model as an OBJ (now
polygons, no longer triangles).  I then use the GIMP (opensource Photoshop)
to color the PNG and apply color to the model.

There may be other and easier tools to use.  Please let me know if you find
something for UV-Maps/Textures that is open source.  You CAN paint directly
on the model in Blender, but I massively dislike the UI.  You can probably
do this conversion and UV map creation with Meshlab, or an online tool.  I
think zBrush is an expensive other options.

I then import the OBJ/PNG/MTL into a Unity3d Project.  I like to create an
instance of my model in my Unity3d scene (think game level), and then I
color the PNG in GIMP and when I save it, Unity3d reloads the file and
shows my changes.  This is probably a little excessive, but it works for me.

Workflow Tip:  Unity3d calls everything you import to work with an "Asset"
and displays them to you in a heirachy.  I create a directory outside of my
Unity3d project to store all the crap that's not directly related to the
game.  For example "non-asset-Space_Invaders/" might include STLs I've
downloaded of NASA asteroid models, OpenSCAD models of spaceships and
shields, and a subdirectory for "developmental_screenshots".  This keeps
Unity3d happier and lets me organize my clutter.
You CAN edit asset files directly in the Unity3d directories.
(I create hard links between certain asset and non-asset files so I'm
always editing the real thing.)

A couple years ago, I did create 2 'games" for VR, compiled them for
Windows, sent them to a friend and ran them on her Oculus Rift.  One was a
simple ball-roller game, which worked fine but was too simple to be
interesting, and the second was a "simple you're standing on a platform look
around" thing.  I didn't have a headset of my own and wasn't able to go
further in that development.  I believe that creating games for Oculus
Quest should be similar.
Unity3d has files/tools for creating VR games.  You might have to download
a (free) asset package form their store.
My currently installed version of Unity3d is old and should be upgraded,
but I'm afraid of what will break and have been delaying.  :-(

I've been told that the free (open source??) SideQuest is the best tool
for sideloading programs into your Quest.
You can probably directly copy the executable and resource to the correct
directory on the Quest's filesystem.`
There is probably something you have to do to sign or approve apps that
don't come from the Oculus store.

Please keep me updated on any progress you make.
Would you be interested in some kind of discussion forum?
Perhaps...a mailing list or discord?

On 2/01/22 9:32 PM, Bryan Lee wrote:

After reading Bryan Lee's comments and a bit of googling, I believe there is such a path. To open it up for walking it, unfortunately, we need to first consider why OpenSCAD developers are not likely to make it available to us lesser critters. The first argument coming from the developers, as Torsten Paul has just recently put it, is Licensing. What I am proposing here is fully Open Source. The next argument I hold against OpenSCAD is that modules do not return values: Modules do create a mesh, i.e. a list of points and faces. But because modules do not make these lists available to the OpenSCAD user, the use of union() or difference() functions builds up a CSG tree, i.e. a huge load on the CGAL rendering engine, a load that could have been much alleviated if each individual use of union() or difference() would have deleted all those points and faces that are no longer needed, resulting in a single line of decisions rather that a complex decision tree. Because OpenSCAD insists on that CSG tree, rendering times will become long . . .
A third argument I hold against OpenSCAD is internal rounding. CGAL, the rendering engine, of cause does not use any rounding. But when leaving CGAL, its results need to be rounded, if only to make it fit into the limitations of the STL file format. And here, we have to consider how the C and C++ languages do rounding by default. And once we have inderstood that, it is no long path to understand how holes in the mesh OpenSCAD produces shows up having holes when viewed in another program, in e.g. MeshLab.
A fourth argument against OpenSCAD is its horrible language, which is so restrictive and memory consuming, leading again towards long development times when compared to a point and click program like the VariCAD I am normally using. To develop a mesh in VariCAD takes me maybe a tenth of the time to do the same thing in OpenSCAD, but then I am seriously limited in what I can design using VariCAD, unlike OpenSCAD, where I have not encountered any limitations ofwhat  I can design.How  I go about designing something is what consumes all the extra time OpenSCAD requires from me. I haven't designed anything that requires hours of rendering time yet, but there have to be such designs, since many users of this forum have commented upon it. I like to have one or two examples, though, not for printing them, but for testing my ideas against them. How much faster can I be?

Here, we need to discard STL files altogether, since the file format is
not designed to contain color information, and neither is, in my
understanding, CGAL. Color availability ends in OpenSCAD with Preview,
Render destroys any color information as far as I know. Let's use the
AMF format instead, for example,  which does support color.

My approach to get there would be this:

Step 1: Replace the OpenSCAD language with Python. John Clark Craig
https://jccraig.medium.com/yes-you-can-use-python-for-3d-design-and-printing-508b1791c863
has demonstrated how to do just this. With his approach,OpenSCAD is used
for display and rendering purposes, with the real design work taking
place transparently in Python. To go this way, we need to use a text
editor to write the python program, a console (in Linux) to run the
program, and OpenSCAD to view the geometry - in other words I need a
large screen such as my 4K 43 inch TV set that I use as monitor to have
the ability to view it all simultaneously on the same display.

Step 2: Force the use of integers in Python for all point coordinates.
Since Python treats integers as having unlimited accuracy, no rounding
takes place, and a source of holes in meshes vanishes. (work in
progress, and I wouldn't mind help there). Since currently I am not
familiar with Python, this step includes to familiarize myself with
Python. Forcing the use of integers for point coordinates also makes
sense from a physics point of view, since there is no way to build
something consisting of 10.946 atoms. OpenSCAD, though, does permit it,
via its implied union() property . . .

Step 3: Use PyMesh https://github.com/PyMesh/PyMesh for rendering. (to
be investigated in detail)

Step 4: Find a way to output the mesh in a color-supporting format such
as AMF.

Step 5: Use OpenVR https://github.com/ValveSoftware/openvr to display
the mesh in a VR headset of your choice.

This is all OpenSource, of course. Putting it all together will take
quite some time, however.

By the way, in my understanding, texture is a way to cover a single face
of a 3D mesh with a 2D picture, and as such is not part of any true 3D
design process. The reason it is used is that it substantially reduces
the need for computing power.

On 03.01.22 00:02, Wolf wrote:

Why are you twisting words?

I said there's no way to integrate WITH THE OFFICIAL SDK
and there's no debate or argument. That is a fact.

The license explicitely states that it's not to be used
in combination with Open Source programs.

There is no choice or wiggle room on OpenSCAD side here.

If you feel the need to complain about that, please target
people who are responsible for that restriction.

ciao,
Torsten.

On 1/1/2022 5:14 PM, Jordan Brown wrote:

It's actually remarkably simple to get a primitive result.

Use OpenSCAD to generate an STL.
Load your STL into Windows' Paint 3D.
Save it as a *.glb file.
Follow the instructions at
https://docs.microsoft.com/en-us/windows/mixed-reality/altspace-vr/world-building/importing-models

And poof!  This gray chair is an OpenSCAD model inside the AltspaceVR
environment on my Oculus Quest 2.

There are a couple of gaps to fill, some on the model side and some on
the AltspaceVR side.

• It's gray.  Perhaps I could paint it in Paint3D.  (But what I really
  want is multi-color / multi-material support in OpenSCAD.  Maybe I
  can make enough time to take a stab at that...)
• It would be nice if OpenSCAD could write the .glb directly.
• It doesn't have physics.  In fact, despite having "collidable" set
  you can walk through it and drop things through it.  AltspaceVR has
  physics; you can have objects that fall and bounce when you drop
  them.  But models imported this way don't, and I don't see any way
  to enable it.  It might be necessary to take the model into Unity
  and give it physics there, but I'm still in my very first Unity
  tutorial.  I don't know about importing stuff into Unity, and I
  don't know about moving stuff from Unity into AltspaceVR.

Anyhow, I knew you all would be excited.