User enhancement requests

[Neil_Taylor]

Samples attached.

1) microgds.

2) what it should look like....

Note that apart from the materials, the geometry is also wrong (see the legs).

regards,

James.

James,
I have checked in detail, and found more information and some history.

It seems there is some ambiguity in the published details of the 3DS file-format, regarding meshes which have been mirrored (as seems likely in this table!). MicroGDS implements one reading of the specification - but we have discovered that ArchiCad, 3DSMax (and others) interpret the spec. another way.

We have a PCR internally to revise this, and I will add your name to this.

(For what it's worth - many other programs make the same mistake we do - for instance, Sketchup...)

I'll also make sure we log another request to improve reading of materials from 3DS files.

[Brian Woodward]

Neil

Remember that 3ds is not a 3ds max native format. To test the validity of a 3ds file you should use Autocad as the format was designed for ACAD. You will find many files that read fine in ACAD but not in MAX

[Neil_Taylor]

Neil

Remember that 3ds is not a 3ds max native format. To test the validity of a 3ds file you should use Autocad as the format was designed for ACAD. You will find many files that read fine in ACAD but not in MAX

Thanks for that reminder Brian - yes - Autocad 2007 interprets the file in the "wrong" manner, with the legs flipped.#

So ... according to the authority (AutoCad) we read the (incorrect) file correctly, but for practical purposes it is clear that the transformed legs should be reversed... A dilemma!

[TimWilkins]

Neil

Remember that 3ds is not a 3ds max native format. To test the validity of a 3ds file you should use Autocad as the format was designed for ACAD. You will find many files that read fine in ACAD but not in MAX

I think it was originally the format for an old 3D Studio (Wikipedia calls this 3D Studio DOS).

[James McClymont]

Ah - yes - we may have seen something like this before.

Which particular file in the archive is this?

Hi Neil,

Thanks for looking into this. The model is called "Table N130510".

Best regards,

James.

[johnwarburton]

I'd like to see the ability to rename styles - ideally from the right-click menu in the document organiser.

All elements that use the style should be updated to use the new named version.

Where a style already exists with the new name, the user should be given the option to use the existing style definition or over-write with the definition that is being renamed, or to cancel the renaming.

[Neil_Taylor]

Hi Neil,

Thanks for looking into this. The model is called "Table N130510".

Best regards,

James.

Thanks James - yes...

Our main problem is that the major competitor programs using .3DS cannot agree how certain features are to be interpreted. If we reverse our current interpretation we would be right for this file (and, apparently, ArchiCad) but will be wrong with certain other programs (e.g. SketchUp and AuoCad.)

A dilemma... we may have to offer a "Mysterious Check Box" on the lines of "tick this and try again if it was wrong the first time" (!)

[Neil_Taylor]

I'd like to see the ability to rename styles - ideally from the right-click menu in the document organiser.

All elements that use the style should be updated to use the new named version.

Where a style already exists with the new name, the user should be given the option to use the existing style definition or over-write with the definition that is being renamed, or to cancel the renaming.

You can already use the Doc. Org. to create a New Style Based On, which provides a renamed copy.

I sympathise with wanting to find and change all occurrences of a style name for another, but tracking down all uses of a style is ... problematic...
Remember that:

• things refer to styles by Name (no direct link)
• In a Project, layers which refer to a style may not be open, and Windows (for Window Style and Window Mnemonics) need not be in obvious folders.
• only in a MAN file can you be sure of knowing all layers and windows...
• so deleting a style may cause later-opened data to find an undefined name

Also, removing a style from the main style file does not wipe all trace of a style, as it may reveal an alternative definition in a lower style file (if the first style overrode the lower style file).

Add in Material Substitution (which may or may not be active), Instances (which use the styles of the document they are inserted into - but cannot themselves be updated), and you have a situation where we continue to feel the user should explicitly choose to Delete the old style after creating the new one, rather than providing Rename which conceals a packaged-up Copy-and-Delete.

[johnwarburton]

You can already use the Doc. Org. to create a New Style Based On, which provides a renamed copy.

Yes, I did that anyway to correct a typing error that I made when creating the first version of the style. But that left me with the issue of changing the style where it was already used in primitives. Being able to rename the style would have addressed the issue that meant that I had to track down and change the style for (more than 500) primitives in lots of assemblies. Something that should have been a simple operation, in my view, was actually very complex.

I know that there is an XML route to dealing with this, but it is not a practical solution for the majority of users.

The relationship between styles and the contents of assembly objects needs some more refinement, I think.

[johnwarburton]

I'd like to see an option on the box and fence move commands to include moving the hook point.

At present the hook point is moved if the entire object is within the box or fence, but is left at its current location if any part of the object is outside the box or fence. Often (though obviously not always) the relationship between the hook point and the graphics is more important than the hook point position and users should have the option to include moving the hook point in order to keep the hook point in the correct relationship with the graphics.

Perhaps a message box - "Keep current Hook positions" and Yes/No buttons should be displayed IF any hook points are found within the box or fence, or perhaps pressing the TAB key to toggle between the two alternative behaviours?

At present, the hook point has to be moved as a separate action by the user and this is clunky - especially when multiple objects are affected.