So I have seen this with saved files and unsaved files, and in very simple models (delete all default content, make a rectangle of any size or shape on a single plane, hide the face and all edges, then draw a line through it). Normally you get the warning that reads your recent operation has caused visible geometry to merge with geometry that is hidden. Ok
FWIW that will crash every time you try it on an unsaved file and in my experience in 2023, its crashing inconsistently, but periodically even with saved files. This is a big problem because anyone who does interiors has to hide roofs or walls etc temporarily to navigate (without say curic portal creating scenes etc) and when you are modeling its easy to end up tying into hidden geometry. This almost never crashed in all previous releases, and certainly shouldn’t be doing so on such simple models.
Reported in Crash #175742 and several others from yesterday in real world scenarios.
Will bug splat a high percentage of the time and afaict almost every time for any unsaved file. Also try generating the message twice consecutively in relatively fast but not immediate succession (say under 2 seconds), that seems to crash every time for me. I have a win 10 machine with Rtx 4090 24gb and 64 gb ddr4. Had no issues like this in 2022 or most prior releases of SU.
It sounds like you aren’t using groups and components correctly. There should be no reason to have new geometry merging with hidden geometry and it wouldn’t if you were grouping the geometry for your walls and roofs.
You should also be giving tags to the groups and components in your model and using them to control the visibility of the objects as you work.
This has nothing to do with whether your file has been saved or not.
Due respect Dave, I have been using SU since version 8 almost every day and have delivered thousands of professional projects for clients. Of course I use groups and components all the time. But I think you would agree when geometry merges with hidden geometry, that was not crashing in 2022 or almost any previous release. I often do group a roof or a ceiling most often, hide them to navigate tighter corridors and models, but there are conditions on which you might inadvertently edit such hidden group or component content and end up merging geometry - these include lofted / follow me’d ceiling trim. It happened to me yesterday modeling a lobby and in that instance, the ceiling was inside a group. I had to restart that model several times so I can’t provide an exact replication of the steps taken, but I think the simpler the better when diagnosing these things - and a box with no groups or components should be as simple as it gets.
If you have a group and that group is hidden and one inadvertently merges geometry with the hidden group then can’t happen if you are outside the group ( and then you wouldn’t know where the group was because it would be hidden unless one has View>Hidden Objects enabled ).
But then if you are actually editing within the hidden group then all new geometry that one draws in the group is hidden and therefore you wouldn’t get the dialog Your recent operation has caused visible geometry to merge with existing geometry that is hidden.
The only time you would get the error dialog is if you had hidden loose geometry and then you drew a loose line that merged with that hidden loose geometry.
Just saying.
But for sure, a bugsplat is a bugsplat and should be looked into…
Correct, but this happens all the time if you quickly hide some geometry to work on something nearby. If you are blocking out a floorplan lets say, and you end up with a ceiling, and you want to add ceiling trim for example, and you don’t take the time to put this into a group because you are ‘under the gun’ and your end of the pipeline is going to flatten the hierarchy anyways, and you wanted to say do a subtractive follow me, its going to crash on you a large percentage of the time. Of course there are ten ways to do this, and some better than others. What I typically do is let the ceiling face select the boundary edges copy those edges some fixed offset, way out of intersection risk on the x or y axis and then just group that, and do the loft /lathe w/ desired profile, close the group and send it back in reverse of that same offset so the trims are in their own containers. But there will be times where there is a gap or something, or the follow me didnt work as anticipated and you don’t want to go showing hidden geometry all the time so it is easy to encounter. The biggest problem is, this crash for some reason seems to not save any type of recovery information / skb or lifesaver after restart. So you can lose as much work as your previous autosave or manual iteration.
Very interestingly, I was about to record two sample videos to show you what is happening, and how easy it is to reproduce in the wild, but when I use Geforce Experience in game overlay to screen record, all the sudden, I couldn’t reproduce the bug splat! Turning it off, it happened immediately and only in SU 2023.
So I guess it narrows it down to being some type of graphics issue. I can record both scenarios in SU 2023 and 2022 with my phone and post later today to youtube and will share links. I will also confirm the same results on my other machine and video that as well which has an earlier nvidia card, a 1080Ti. Nonetheless, the crash needs to be handled a bit more elegantly.
If you work properly that shouldn’t happen even inadvertently, that means you’ve hidden loose geometry before making it group or component, it used to happen inadvertently to me years ago when I just started to use the program and my models where very messy.
All well and good, false economy point taken, but I would like to point out that if you explode a group not realizing you may create an intersection with loose hidden geometry (perhaps even from imported work), its very easy to stumble into this, and importantly, it was reproducible only in this version where it lost effort and progress with no recovery - that leads me to believe that other splats are falling into that category of crash that is inelegantly handled.
I don’t know what happened but now I can only reproduce the bug 1 in 10 times so its been tough to video examples. I upgraded nvidia drivers last night on both machines to 536.67, but it was still happening this morning more than once in several tests, until I tried to screen record using geforce experience - suddenly even after reboots on the machine I am on now, its very difficult to reproduce (good news) - but I suspect may still be happening some lesser percentage of the time. Perhaps there was some new fancy direct draw going on? I remoted into the other machine, tested the same on the same nvidia driver version and also had trouble reproducing, so that may be the culprit.
and it must have been back then, the last time when I wasn’t grouping.