@Sean Tried to reproduce the gdiff issue in MGED with moss.g:
cp all.g all2.g
e all2.g
oed / all2.g/box.r/box.s
tra 10 0 0
accept
e all.g
gdiff all.g all2.g
I see visual differences, at least on Linux...
Thought... do any of the commands other than gdiff do significant raytracing in the same process as MGED itself? rt, rtcheck and nirt are all separate programs...
/me is wondering if the combination of calling prep and xpush in the same process is why this is happening now with d_use_hd
@Sean Interesting... trying to zero in on the cause, I did the following in xpush.c:
Index: src/libged/xpush/xpush.c
===================================================================
--- src/libged/xpush/xpush.c (revision 78049)
+++ src/libged/xpush/xpush.c (working copy)
@@ -260,6 +260,10 @@
RT_CK_DIR(dp);
+ struct rt_i *rtip = rt_new_rti(gedp->ged_wdbp->dbip);
+ if (rt_gettree(rtip, dp->d_namep) < 0) return NULL;
+ //rt_free_rti(rtip);
+
if (!(dp->d_flags & RT_DIR_SOLID)) {
bu_vls_printf(gedp->ged_result_str, "Copy_solid: %s is not a solid!!!!\n", dp->d_namep);
return RT_DIR_NULL;
If I'm understanding correctly, that should be a no-op as far as xpush is concerned? However, in the above form, xpush crashes in Free_uses. If I uncomment the rt_free_rti, I get the following:
/bin/mged share/db/moss.g cp\ all.g\ all2.g\;g\ all\ all.g\ all2.g\;xpush\ all
Ran out of uses for combination all.g
Failed to copy object all.gRan out of uses for combination all2.g
Failed to copy object all2.g
Am I missing something?
/me puts on his hip waders and heads into the xpush code...
Last updated: Jan 09 2025 at 00:46 UTC