Best Of

Early in the design process, it can make a lot of sense to have everything all in one document, except maybe purchased parts or anything else you know isn't likely to change. However, it does slow things down. It really depends on how much you're waiting for rebuilds. If the performance hit isn't making you miserable, it may be fine to keep things in a single document as long as you can. Within a single document you can switch derives and assembly instances from workspace references to version references and back, if you want. This can help control some of the rebuilds and get you ready for splitting out the tabs into separate documents later.

Keep in mind that a document has one history tree. You can branch and merge, which is powerful, but this affects every tab in the document. At a certain point, even as a team of one, you'll run into things where it would be nice to have some things in separate documents to have more fine-grained control over this.

You can also try splitting out tabs into other documents and if it's too annoying, you can move them back.

Without seeing the complexity of your parts or part studios, it's hard to tell how much pain you might be creating with a single document, but things like imported parts and drawings do start to sound like you really could split things out. Imports are typically pretty static. Drawings aren't live anyway (you have to refresh them manually).

Keep in mind that versions are free. I often make several in a day just to mark major progress, so if I really screw something up, I have a clear place to revert to. I leave the "Vxx" in the name and just add a short reminder of what changed in the name. Sometimes I'm lazy and just leave the "Vxx". It really takes a second or two. Updating all the dependent tabs to the latest references can be tedious, but getting used to this process is valuable.

To some degree, this all depends on how you are prototyping or releasing your parts for production. When you start making prototypes, you don't want to make new parts that have the same geometry just because some references got updated. You'll want to be more deliberate about revisions. Certainly once tooling is involved, things get a lot more expensive to change and you don't want a part to change without notice.

I do hate potholes too. 😂 But your right technically not a Complaint toward onshape....but I guess it could be depending on your point of view. My ISP is the only choice we have so I can't be using the wrong one. Ha.. Starlink night be possible. Haven't checked into that in a while. Redundant connection makes sense in theory. But doesn't make sense until my life depends on it. Might not even resolve the issue I'm having tbh since it would just be a second line from the same stupid company.

Also if all the parts from one part studio are not moving relative to each other, you can use the "insert as rigid" option and then any new parts from that part studio will be added automatically.

I created several parts studio's , one is quite complex with multiple parts, drawn in situ. I then added the parts studios to an assembly studio within the same document. For the multipart, complex part studio, I imported all parts at once and Grouped them to maintain thier relationship to each other. I am also creating drawings from the assembly studio. I discovered some errors and went back to the main parts studio and made several changes, including making new parts. These changes were not reflected in the assembly(at least the new parts do not appear). I tried to create a revision of the parts studio, but the blue update circle in the assembly is not active.

Is there an easy way to update this parts assembly, or do i have to insert each new part individually and fasten them in the assembly?

update:

NEVER MIND. I inserted and fastened each new part. it wasn't as bad as i thought.it would be.

That looks awesome!
I second @S1mon 's request for a lambertian distribution (I guess under the "Rays/Shape"?)

Another thing that could be super useful would if there was a way to visualize a "heatmap" on the target.
I can see how that could be tricky to do but maybe dividing the target surface in x sub-surfaces and applying a color based on the relative number of hits/area? Or even doing it manually for each selected target (i.e. do a zero offset surface of each one and apply a color based on density of hits).