Loading...
> >

When sending an .obj over the Bridge to D/S ?

patience55patience55 Posts: 7,006
edited December 2013 in The Commons

When sending an .obj over the Bridge to D/S, why in blazes does it add "def_sur_mat"? It is NOT in the .obj, nowhere. Direct import into D/S is 'clean'. Just from the Hexagon Bridge over whether it's started in Hexagon or an .obj swap to send back to D/S.

Information appears then in the created .duf file and cleaning that is like, impossible.

Why? How to stop this? Ideas?

Post edited by patience55 on

Comments

  • JimmyC_2009JimmyC_2009 Posts: 8,891
    edited December 1969

    Hexagon creates this material by default. When you save as an OBJ (not using the bridge), it is written out to the MTL file, and can be deleted there.

    I don't know of any way to stop Hex from sending one to DS

  • patience55patience55 Posts: 7,006
    edited December 1969

    JimmyC_2009 said:
    Hexagon creates this material by default. When you save as an OBJ (not using the bridge), it is written out to the MTL file, and can be deleted there.

    I don't know of any way to stop Hex from sending one to DS

    Thanks for replying.

    Sigh, ... well, I have over time learned that one can import that first .obj back into a new opening of Hexagon, delete all but the desired material, export out that .obj file and yes, that will be "clean" of that silly "default mat" reference. But even for that "clean" one, yes, Hexagon is recreating it OR D/S is adding it over the Bridge ... "make work projects" --- you know, 'tis my humble belief that over all more people would be creating more things IF programs actually "did what they were told to do as expected by the customer" as opposed to being "helpful and adding things just because" ...

    From the .duf file though, so far manual edits have only created more goofy surface names in D/S than one knew could possibly exist.

    Another project 'tossed'. :-(

Sign In or Register to comment.