Stream: brlcad

Topic: gdiff


view this post on Zulip starseeker (Jan 06 2021 at 13:48):

@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...

view this post on Zulip starseeker (Jan 06 2021 at 21:50):

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...

view this post on Zulip starseeker (Jan 06 2021 at 21:51):

/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

view this post on Zulip starseeker (Jan 07 2021 at 14:12):

@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?

view this post on Zulip starseeker (Jan 07 2021 at 14:21):

/me puts on his hip waders and heads into the xpush code...


Last updated: Oct 09 2024 at 00:44 UTC