Java 3D CAD program - volunteer opportunities

Seeking volunteer(s) to assist with enhancing a Java CAD program I have been developing since 2017.

CM (Compartmentalized Model) Creator can model compartmented structures such as buildings, ships, space stations, and the like. Unlike AutoCAD-type software, which are parts modelers intended for use in full-scale production, CM Creator is a 'total platform' modeler intended for creating 3D-printed scale models (prototypes) rather than the real thing. When transparent materials are used for the 3D printing, the scale models produced would be at least partly transparent, potentially allowing the internal structure (compartments) to be visible in addition to the exterior as in all current scale models. The ability to create transparent scale models of subdivided structures could open new markets for 3D printing. (Note: 3D printers cannot print totally enclosed hollow objects, but CM Creator is designed to provide a way around this,)

While CM Creator currently can create 3D digital models of complex compartment structures, code to prepare the 3D models for input to 3D printer pre-processors still needs to be written.

More to the point of this forum, CM Creator currently displays its 3D digital models in wireframe only. Rather than write hidden line code to enhance the display of the digital models, it would be much better to use Java3D.  Java3D would not only provide hidden line, but also the ability to do virtual reality walkthroughs of the subdivided structures. This Java3D code need not be written from scratch because I wrote such code 20 years ago when Java3D was new. However, this code was designed to operate as an applet that would give browsers such as Netscape and Explorer virtual reality capability for things like on-line shopping (example: the Walmart website would be a Java3D model of a Walmart store, and the user would shop for products similar to being in an actual Walmart.)  Sun management then decided to not support Java3D and, worse, support for plugins like applets were discontinued in browsers, and applets were deprecated. Thus, the existing Java3D display code for subdivided structures needs to be refactored and enhanced for use in CM Creator.

This is just the top of the iceberg of things that can be done with CM Creator's 3D digital models -- and I can't do it all myself.

If you are interested in contributing to an application with real world utility that has a strong need for Java3D, please contact me.  If you want to look at CM Creator before deciding, it is available on github at
https://github.com/rlutowski/CMCreator  The latest version is v0.6.

Hi Rick,
I glanced over your git repo and besides the jar and zip files (one set hints at source code)
with a different (project?) basename - well, I couldn't see source code.

Perhaps it might help if you elaborate a little bit about the status
for our audience.

Thank you.

~Sven

.. or in other words, I would:
- commit the source code in a sub-folder like e.g. 'src'
- add a build recipe, allowing users to build the beast
- add directions to do so in the old fashioned but 'new' (markup)format README.md

.. just my 2c ..

Sven, thanks for your response. Your suggestion is well-taken.

I should point out that I'm currently not using github for development and version control purposes as it is intended to be used, but simply as a 'dumb' distribution directory where anyone can download the install and source files.  There are two reasons for this:

1. It makes it easier for designers, model builders, and others who do not know programming and github usage to download the files.

2. I myself have not taken the time to learn the proper use of github for joint development since, up to now, the project has not been a joint effort.

If other Java3D developers decide to get involved, I would need to help them get up to speed with CM Creator internals, and they would need to help me get up to speed with using github for joint development -- probably using a different directory tree such as /jreality/CMCreator or java3d/CMCreator instead of rlutowski/CMCreator.  (The latter could still be available for download of completed releases by non-programmer users, as it is now.)


As for the files in  rlutowski/CMCreator,, the latest install files are
jreality_v0.6-mac.zip
jreality_v0.6_linux.tgz
jreality_v0.6-win.zip

and the install directions are in
README_v0.6-linux
README_v0.6-mac
README_v0.6-win

The Java object code for Windows, Mac, and Linux is identical.  There are different distros for each system because the install scripts for each system use os-dependent script syntax.


The source code is in
jreality_v0.6_src.tgz

This is in linux gzip format.  Win and Mac users need to install gzip (gnu zip) to unpack the source.  I tried creating a .zip for the source, but the file size was HUGE!  gzip is so much more efficient that it is the best way to distribute the source in one file.

The source files are adequate for users to view the source, but not for developers to re-build it.  For that, additional build scripts are needed, which are probably best put in a github 'build recipe' as Sven suggested.  One of the first tasks for anyone who wants to help is to assist me in doing this since I am not currently conversant with proper use of github.

Hope this helps.

Hello

You're plain wrong in my humble opinion, I advise you not to do that. You can totally create a small web page with a link to the release section in which your users can download the files easily. Moreover, using a versioning system that way is terribly inefficient and it doesn't help to track the changes. Sorry to be harsh but an experienced developer would probably find your current repository dumb and noobish.

This is my personal opinion but I don't even advise anybody to use Github, some alternatives exist, you could use Git elsewhere, on Gitlab, and move it on your own server later.

Rick,
This looks interesting, I'm trying to get the code running, but the src zip doesn't seem to have
com.jreality.geometry.shape3.ClosedFacetedSurface;
in it?
How do I get that?

gouesse wrote:
> using a versioning system that way is terribly inefficient and it doesn't help to track the changes

From a purely technical standpoint, you are correct.  I'm not happy with using github purely as a distribution mechanism; it would be easier and cleaner to post the distros to my website.  However, several non-technical considerations influenced the decision to (mis)use github as a distribution mechanism.  These are: (1) age, (2) collaborators, and (3) CM Creator content.

Age:  When version 0.1 of CM Creator was ready for release, I was over 70 years old. When you get to that point in life, issues relating to personal longevity start to influence your thinking.  You might have 20 years left, or 20 months, or 20 minutes. Planning would be far easier if you know which, but you don't. So you hope for the best, but plan for the worst.

Collaborators:  CM Creator has been a one-person project from the beginning.  Among my friends, one programs in Java, but his interests lie elsewhere. Other close friends have backgrounds in design or modeling, but none are programmers.  That left just me to pursue CM Creator.

CM Creator content:  Most people learn a lot in 50 years of professional life. Some choose to pass on part of that knowledge by writing books. Others, by making movies. Others teach or give seminars. For me, it is by writing CM Creator (and one book on software development, which CM Creator utilizes.)

When it came time to release v0.1, all these factors came into play:

"Posting the distro on my website would be clean and easy.  However, my website dies when I do. With no collaborators, there are no other repositories or sources. Thus, when my website dies, CM Creator and all the unique knowledge contained within it dies too.

"Posting the distro on github is tacky; github is not well-suited to that.  However, github will not die when I and my website do.  Without collaborators, development will stop and there will be no other sources, but all releases will survive as long as github survives.  Like the Ark of the Covenant in Raiders, CM Creator may become lost among thousands of other projects in the github warehouse, but it will still be there waiting for some future explorer to re-discover its secrets.

Survival or death?  I will choose survival, and post CM Creator to github."

Of course, collaborators would totally change this analysis, and its conclusions.  CM Creator could use github as a collaboration and version control mechanism as intended. Distributions would be posted at public locations as determined by the development team.  Development would not cease when I'm gone; the unique knowledge contained within CM Creator would become known to the development team and evolve through their continuing innovations.

Thus, the decision of how CM Creator utilizes github going forward is up to you, the reader.

philjord wrote:
> I'm trying to get the code running, but the src zip doesn't seem to have
> com.jreality.geometry.shape3.ClosedFacetedSurface
> in it?
> How do I get that?

Interesting!  The are short, long, and longer answers to this.

Short answer:

You can get the com.jreality.geometry.shape3 package at
http://www.jreality.com/downloads.html
Use the download link "Version 1.1.1 (937467 bytes)"

Long answer:

At first your question threw me because ClosedFacetedSurface is not used by CM Creator, so is not included in the src.tgz file.  A little poking around made me remember I referenced it in a @see statement of com.jreality.cmodel.rcs_geom.IntegrableSurface3 -- which tells me you are running javadoc on the source.  I have not run javadoc on CM Creator for a long time, so you are likely to encounter many more javadoc errors than this!  Unless you would like to clean up the javadoc comments as your first contribution, you might want to skip running javadoc for now.

That being said, helping to document a program is a great way to get up to speed with it.  Once I was tasked with writing the user manual for a large in-house graphics package. Writing the manual made me so familiar with the code that I became the "program mother" for the package.

Longer answer
or
What is ClosedFacetedSurface, and why does CM Creator not use it?

What is ClosedFacetedSurface?

The post that initiated this thread refers to an early java3d applet that was intended to enhance mainstream browsers like Netscape with VR capability.  That program is called CM Surveyor.  ClosedFacetedSurface is the class CM Surveyor. uses to model closed 3D surfaces in a manner compatible with java3d.  (see footnote)

Why does CM Creator not use it?
Reason 1

CM Creator uses a class called com.jreality.cmodel.rcs_geom.IntegrableSurface3 to model closed surfaces. The javadoc comments for IntegrableSurface3 explain how it differs from ClosedFacetedSurface. In a nutshell, ClosedFacetedSurface is designed to support _display_ of compartmentalized models using java3d, whereas IntegrableSurface3 is optimized for fast interpolation, integration and similar operations used to _create_ and _analyze_ compartmentalized models. Thus, one of the tasks in merging CM Surveyor's java3d engine with CM Creator is to write a method that converts an IntegrableSurface3 object to a ClosedFacetedSurface object.  Because both classes model surfaces in fundamentally the same way, this conversion should be quick and fairly painless. (The devil is in other details...)

Reason 2
For those who don't mind my diving deeper, I discovered a design lesson here as well.

In support of CM Surveyor I developed an extensive set of 2D and 3D geometric modeling classes based on a systematic analysis of all logically-possible geometric objects, 38 different geometric objects were identified, from a simple 2D point to complex 3D surfaces. Each geometric object was modeled by its own class, and the classes organized into 3 packages. Even though CM Surveyor only needed a small number of those 38 classes, I figured they would save development time in future geometric applications.

Later, when trying to use these packages in designing CM Creator, things got sticky.  Eventually I concluded that basing a package design on a comprehensive analysis of a problem space results in what might best be termed "over-modularization."  While the design faults of the "massive main" were long ago recognized, I concluded it is also possible to go too far the other way.  The best solution is somewhere in the middle. Thus, CM Creator does not use the CM Surveyor geometric modeling packages, but has its own set of much leaner ones.

----

Footnote: CM Surveyor _is_ available on my website. When I wrote it 20 years ago (1) I was younger, (2) figured I could form a successful business creating VR websites enabled by CM Surveyor (so longevity and successor issues were not the drivers they are now), and (3) github didn't exist then!

Dear Rick,

1st of all - my full respect to even publishing your work
and exposing yourself to our bunch - not always easy :)

It's surely up to you how you utilize the decentralized revisioning system
and its really not our call to 'tell you', only to debate and share our opinion.

So the first task for somebody willing to jump into your project
would probably be to compile the code and reproduce a working binary.
When this is done, such person might be willing to create a README recipe
and do the errand of creating a new repo with source and all our usual 'crap' :))

Then you would have a fruitful collab perhaps and you would also see
how this new git thing works .. at least a little.
And then .. the real work & fun may start.

To preserve ones work, it is a good idea to spread your code around, gitlab, github, gitflic.ru even, whatever helps.
So you already did the 1st important step - potential users / coder may thank you for that.

I myself have not much time yet for this your project myself,
but perhaps others are willing.
What I find quite attracting are demo videos showing some results
and hence sweetening, lowering the pain threshold of 'jumping in'.
In case you can make a video somehow and post it here (or via good/evil whatever),
you might can attract more potential developer.

Cheers and great you keep coding & doing stuff.

EDIT: Seems you already have one, thank you philjord!

Sven wrote:,
> 1st of all - my full respect to even publishing your work
> and exposing yourself to our bunch - not always easy :)

If I read the stats right, this forum has 1360 users.  Compared to the millions of Java developers, those of us interested in java3d would qualify as an elite group.  I feel among friends just based on that.

In any case, I'm used to dissent. Try going to any of the methodology forums with a totally new requirements development paradigm. Talk about taking heat from skeptics!
 
Spoiler alert: CM Creator uses this methodology, called "Freedom," which evolved from a methodology developed for NASA's Space Station Freedom Project. The Java-Freedom combination has resulted in CM Creator being much better structured. and more functionally capable, than originally anticipated. Anyone who volunteers can expect to learn a little about Freedom (well, maybe more than a little.)


> So the first task for somebody willing to jump into your project
> would probably be to compile the code and reproduce a working binary.
> When this is done, such person might be willing to create a README recipe
> and do the errand of creating a new repo with source and all our usual 'crap' :))

That would be great!


> Then you would have a fruitful collab perhaps and you would also see
> how this new git thing works .. at least a little.

Yes, of course.


> And then .. the real work & fun may start.

The 'to do' list is long, so a volunteer will have a lot of choices. Have already mentioned enhancing display capability with java3d, and interfacing with 3D printers. Those are big tasks, but there are many smaller ones, such as
* re-implementing my old linear-time sort library in Java (CM Creator could use a super-fast sort!),
* adding code for 2nd moment/gyradius computations,
* adding code to punch holes (called "Reference Removals") in surfaces,
* adding html links to the JToolTip-based help package,
* formulating a better algorithm for an especially challenging interpolation routine,
* enhancing and further debugging the units conversion package,
... the list goes on and on.


>To preserve ones work, it is a good idea to spread your code around, gitlab, github, gitflic.ru even

Not sure I was even aware of gitlab, but the suggestion makes sense.  Would be a matter of a volunteer stepping up to spearhead it.


> What I find quite attracting are demo videos showing some results
> and hence sweetening, lowering the pain threshold of 'jumping in'.
> In case you can make a video somehow and post it here (or via good/evil whatever),
> you might can attract more potential developer.

Prepare to be shocked.

I could blame this on my age, but it is really just a total lack of interest in cell phones.

Not only have I never created a video, I have yet to snap a camera shot with my cell, which I never use for anything other than voice calls, and rarely for that. I contemplated ditching my cell totally to save the monthly bill, but my wife talked me into keeping it in case we needed it for an emergency.  So posting a video is a non-starter. However, I will try to post some screen shots of CM Creator. Best I can do.

In any case, videos should not be necessary to learn how to use the program.  One of CM Creator's features is an enhanced JToolTip package that pops up a help window whenever the mouse passes over a component like a JButton or JTextField.  The window describes the operation of the component. I call this JIT (Just-In-Time) help.  It takes the place of a separate user manual by essentially building the user manual into the program. The idea is that a new user can learn to use the program as they use it rather than reading a manual or viewing a video, then trying to remember what they read/saw when they start using.  I don't know of another program that operates this way, so feedback on the effectiveness of JIT help from a few actual new users would be enlightening.

Screenshots

Below is a screenshot of CM Creator's primary test case -- the battleship Texas.  It shows the first-level subdivision of the ship in section view.  Section slices can be taken at any location in each of the 3 views. The main menubar options are at the top, and the display controls are under the section views.

CM_Creator_1.png


Below is a screenshot of the battleship Texas test case in rotated view.  CM Creator does not really support rotated views at this time, but can be forced into it by using one of its rotation options in an unintended manner.

CM_Creator_2.png

This view makes it pretty clear why the program needs java3d, and why rotation of the entire model is not currently supported -- without hidden line, rotation does not provide much cognitively useful information.

To the left of the image is a pop up help window for the "Creator_0.6+" menubar menu item.  This particular help page is special in that it describes the layout of the entire main window rather the menu item specifically.  Thus, it should be one of the first help pages read by new users.

Rick,
I always enjoy the challenge of getting code running so I'll just crash on.

package com.jreality.cmodel.rcs_subdiv.Partition from jreality_v0.6_src.tgz

has
import  com.jreality.geometry.shape3.ClosedFacetedSurface;

Which as your commentary above eludes to causes dependency bloat, if I throw the geometry package from surveyor 1.1.1 I need  behavior then surveyor itself and it goes on

If I put just ClosedFacetedSurface in on it's own it needs heaps of the rest of it's own package

import  com.jreality.geometry.ShapeObject;
import  com.jreality.geometry.QuadPatch;
import  com.jreality.geometry.TriPatch;
import  com.jreality.geometry.DimensionalityCollapser;
import  com.jreality.geometry.InvalidSegmentException;

So I imagine you have a copy of Partition that does not have the import required? only Partition read and write need this class.


While I'm here the

com.jreality.creator.gui.CreatorMenubar
needs
import  com.jreality.creator.gui.menu.RefSurfaceMenu;
which is not in the src

and
com.jreality.cmodel.ExtSurface
also wants
import  com.jreality.geometry.shape3.ClosedFacetedSurface;


Thanks,
Phil.

philjord wrote:
> package com.jreality.cmodel.rcs_subdiv.Partition from jreality_v0.6_src.tgz
> has
> import  com.jreality.geometry.shape3.ClosedFacetedSurface;

Yes. Early on I anticipated incorporating java3d into CM Creator using CM Surveyor libraries, so I put in some 'hooks' in anticipation. These hooks may or not survive the actual java3d incorporation depending on the eventual design, but are there now.

To resolve these dependencies, install CM Surveyor sources first, then CM Creator.  When you are done, the directory

<system dependent path>/src/com/jreality

should have the package subdirectories

behavior  -- CM Surveyor packages, might be used by CM Creator java3d
cmodel    -- CM Creator packages
creator    -- CM Creator packages
geometry -- CM Surveyor packages, also supports CM Creator java3d
io             -- packages used by both
surveyor  -- CM Surveyor packages, some sub-packages also support CM Creator java3d
util          -- packages used by both

You can then compile the .java files, CM Surveyor first.  I don't remember if a compile script was included in the CM Surveyor distro.  If not, this (linux) script used to work:

#javac -Xlint:unchecked -d /usr/local/_jreality/  \
javac -d /usr/local/_jreality/  \
/usr/local/_jreality/src/com/jreality/surveyor/gui/*.java  \
/usr/local/_jreality/src/com/jreality/surveyor/sg/*.java  \
/usr/local/_jreality/src/com/jreality/geometry/*.java  \
/usr/local/_jreality/src/com/jreality/geometry/shape2/*.java  \
/usr/local/_jreality/src/com/jreality/geometry/shape3/*.java  \
/usr/local/_jreality/src/com/jreality/geometry/sg/*.java  \
/usr/local/_jreality/src/com/jreality/behavior/*.java  \
/usr/local/_jreality/src/com/jreality/io/*.java \
/usr/local/_jreality/src/com/jreality/util/*.java \
/usr/local/_jreality/src/com/jreality/util/gui/*.java \
/usr/local/_jreality/src/com/jreality/util/math/*.java \
/usr/local/_jreality/src/com/jreality/util/search/*.java \
/usr/local/_jreality/src/com/jreality/util/units/*.java \
/usr/local/_jreality/src/com/jreality/demo/freedomship/*.java \
/usr/local/_jreality/src/com/jreality/demo/outfit/*.java \
/usr/local/_jreality/src/com/jreality/demo/prefab/*.java \
/usr/local/_jreality/src/com/jreality/demo/riverbend1/*.java \
/usr/local/_jreality/src/com/jreality/demo/riverbend2/*.java \
/usr/local/_jreality/src/com/jreality/demo/superstore/*.java

Unfortunately, this script now gives a bunch of errors about missing classes in the packages
javax.media.j3d
javax.vecmath

As mentioned earlier, CM Surveyor was written when java3d first came out.  I would guess these j3d packages no longer exist.  Rather than updating CM Surveyor to the latest java3d, just comment out the script lines that trigger the errors.  The only lines above you should need for now are the ones that compile the first 3 geometry packages

/usr/local/_jreality/src/com/jreality/geometry/*.java  \
/usr/local/_jreality/src/com/jreality/geometry/shape2/*.java  \
/usr/local/_jreality/src/com/jreality/geometry/shape3/*.java  \

plus
whatever /util/ packages they need.


> com.jreality.creator.gui.CreatorMenubar
> needs
> import  com.jreality.creator.gui.menu.RefSurfaceMenu;
> which is not in the src

Delete this import from CreatorMenubar.java.  It should not be there.

Now, compile CM Creator using the compile script in the CM Creator distro.
Hopefully, this will resolve the dependency problems

 philjord wrote:
> package com.jreality.cmodel.rcs_subdiv.Partition from jreality_v0.6_src.tgz
> has
> import  com.jreality.geometry.shape3.ClosedFacetedSurface;


My previous post responding to this issue does NOT fix the problem. I tested the proposed solution before posting it, but the test was compromised by a 20 year old "ClosedFacetedSurface.class" file that was lurking on my system that I had forgotten about.

The real solution consists of 2 steps.

Step 1 -- Create a stub of ClosedFacetedSurface,java to resolve the dependency link. The method doesn't have to be functional because CM Creator does not actually call it (yet).  The stub method goes in package  com.jreality.cmodel.rcs_geom

Step 2 is to change all references of the form
com.jreality.geometry.shape3.ClosedFacetedSurface
to
com.jreality.cmodel.rcs_geom.ClosedFacetedSurface

Such references occur in the methods
com.jreality.cmodel.rcs_geom.IntegrableSurface3
com.jreality.cmodel.rcs_subdiv.Partition
com.jreality.cmodel.rcs_subdiv.UNormalPartn
com.jreality.cmodel.rcs_subdiv.VNormalPartn
com.jreality.cmodel.rcs_subdiv.VNormalPartn
com.jreality.cmodel.ExtSurface

Most of these are import statements.

With these 2 steps completed, the compile script ".compile_creator" provided in the _src.tgz distro file should work ok.  CM Surveyor is not needed at all.  These changes have been made to the CM Creator master files and will be in the next release to avoid these issues in the future.

Here is the source for the  stub class that can be cut and paste into your CM Creator source directories, for anyone so inclined:

-----------------------------------------------------------------------------------------------------------------------------

/*                      com.jreality.cmodel.rcs_geom.ClosedFacetedSurface
 */
package com.jreality.cmodel.rcs_geom;

import  java.io.DataInputStream;
import  java.io.DataOutputStream;
import  java.io.IOException;

/*
 * Application: Compartmentalized Model Package
 *
 * Copyright (C) 2023 LDJ Trust.
 *
 * This file is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version 3
 * of the License, or (at your option) any later version.
 *
 * This file is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this file; if not, see https://www.gnu.org/licenses/
 *
 *
 */
/**
 * Class Purpose: Model a closed 3D surface of arbitrary shape
 *                in a manner compatible with java3d.
 * <p>
 * Notes:  This method is a stub for the real ClosedFacetedSurface
 *         located in package com.jreality.geometry.shape3.
 *         The real version is strongly tied to an old version of
 *         java3d, and needs to be updated for new versions of java3d.
 *         In the interim, this stub can be used to resolve CM Creator
 *         references to this method.
 */
public class ClosedFacetedSurface extends Object {

/*
 ******************************************************************************
 *                      Field Variable Declarations
 ******************************************************************************
 *
 *                      Private Instance Fields
 */
/*
 ******************************************************************************
 *                      Constructor Methods
 ******************************************************************************
 *
 *                      ClosedFacetedSurface Constructor #1
 */
/**
 * Purpose:  Default constructor for the class.
 * <p>
 * Notes:  Intended for use during deserialization only.  Applications
 *         should use the argumented constructors for shape object creation.
 * <p>
 */
  public ClosedFacetedSurface ( ) {
    super();
  }
/*
 ******************************************************************************
 *                      Object Behavior Methods
 ******************************************************************************
 *
 *                      ClosedFacetedSurface.write
 */
/**
 * Purpose: Write this ClosedFacetedSurface object to file.
 * <br>
 * Notes:
 *
 * @param dos  DataOutputStream for writing the ClosedFacetedSurface data.
 * @exception IOException  problem writing file,
 *                         such as insufficient permissions.
 */
  public void write (DataOutputStream dos)
             throws IOException
  {

    return;
  }
/*
 ******************************************************************************
 *
 *                      ClosedFacetedSurface.read
 */
/**
 * Purpose: Read a ClosedFacetedSurface object from file.
 * <br>
 * Notes:
 *
 * @param dis  DataInputStream for reading the ClosedFacetedSurface data.
 * @param units  Specific Units in which the ClosedFacetedSurface was stored
 *               on file.
 * @exception IOException  problem reading file,
 *                         such as insufficient permissions.
 */
  public void read (DataInputStream dis, String[] units)
            throws IOException
  {

    return;
  }
/*
 ******************************************************************************
 */
}                   // End of com.jreality.cmodel.rcs_geom.ClosedFacetedSurface

-----------------------------------------------------------------------------------------------------------------------------


I apologize for the previous wild goose chase.  

On the positive side, it did serve as an intro to CM Surveyor, which is planned to serve as the bridge for implementing java3d in CM Creator, and identified some of the challenges involved.