User enhancement requests

[johnwarburton]

One topic that came up at the recent User Group was the difficulty in matching rendered scenes to the user's perceptions. A particular example was that of ceilings being darker than client's expect when rendered in accordance with the physical lights.

Perhaps one way to address this would be to add a "Lit Appearance Factor" to most materials. Say a scale of 0-100% where 0 was equivalent to letting the physical lights control the result, while 100% would be exactly the same as using the Lit Appearance shader.

I would expect users to set a low value that would represent the minimum brightness that would be rendered for the material. Where the physical lights illuminate the surface to a level less than the percentage set by the shader definition, the lit appearance value would be used, otherwise the illumination calculated by the renderer would be used.

This would give a more sophisticated degree of control than simply adjusting the scene exposure or using fill lighting.

[johnwarburton]

At the moment, we have two mechanisms that link objects.

The first is the use of instances, where each instance of an object is linked to the original object in an external file. Edits to the original are reflected in the original.

The second is the use of assemblies, where objects can be linked with other objects (grouped) so that transformations applied to the assembly are applied to the group so that the relationship of objects within the group is maintained.

Assemblies can also be instances of course.

I would like to see a third mechanism.

I would like the ability to link a group of objects such that an edit applied to one object applies to the linked object. There would be two types of linking.

1. If the objects are identical, the linked objects should behave like instances, but would not reference an external file. e.g. changes to the primitives that make up the object should be reflected in all of the identical linked objects.

2. For all linked objects (even those that are not identical) transformations that are applied to one object would be matched by all the linked objects. The point of reference would be the object hook point. If one object is moved and/or scaled and/or rotated and/or copied, the linked objects would also be moved/scaled/rotated/copied by the same amount.

A method of unlinking and relinking would be required, as would an over-ride so that the linking could be disregarded or applied selectively (in the same way that Set Edit filters can be turned on and off.

[johnwarburton]

The grid, when set, does not display in perspective views.

I would like to see the grid display in perspective views, at least on the XY plane.

Options to show grids on the XZ and YZ planes would be useful too.

This is going to become more important with the introduction of intelligent objects.

[Neil Harris]

The grid, when set, does not display in perspective views.

I would like to see the grid display in perspective views, at least on the XY plane.

Options to show grids on the XZ and YZ planes would be useful too.

This is going to become more important with the introduction of intelligent objects.

I would also like the option to include the grid in printing - it can often save time explaining relationships & sizes.

[johnwarburton]

I'd like to see a new property available to linestyle definitions.

Where primitives of an identical closed linestyle touch or overlap, I'd like to be able to specify that the group of touching or overlapping closed primitives are displayed as if they were a single primitive.

Primitives in the same style that are entirely enclosed should behave as specified for loops.

Variations for this behaviour should be to allow the behaviour for:

1. primitves in the same object only
2. primitives on the same layer only
3. all primitves

[DarkSide]

I would love it if the programmers could rethink this problem before shipping out the new version. Without a new Environment Copy program, most users might just decide to stick with ver 10 and avoid the headache of changing the interface to match their current one. What are we going to do? Take a print screen of our toolbar setup and write down all of our shortcut keys? Then spend hours trying to figure out how to change the new version. When you go to a new version it should be an easy process not one that will give the users a big headache.

[johnwarburton]

I would love it if the programmers could rethink this problem before shipping out the new version. Without a new Environment Copy program, most users might just decide to stick with ver 10 and avoid the headache of changing the interface to match their current one. What are we going to do? Take a print screen of our toolbar setup and write down all of our shortcut keys? Then spend hours trying to figure out how to change the new version. When you go to a new version it should be an easy process not one that will give the users a big headache.

What makes you think that the final release installation won't respect user settings? I'm not saying that it definitely will - I don't know, but none of us do.

As for getting to grips with transferring settings manually, the new mechanism is so much better than the current system that everyone should want to do it.

[johnwarburton]

Current behaviour for keyboard snap overrides is that the key pressed overrides the snap at the current cursor position.

I'd like to see an optional behaviour where pressing a keyboard override forces MicroGDS to recognise only the selected snap type until a snap is made, then revert to normal behaviour.

i.e. define override, then find the position instead of find position, then define override.

[johnwarburton]

The highlighted entries in the Document Organiser indicate the default windows and views. This is actually slightly confusing when several windows or views are open.

It would seem to me to make more sense and be more useful to have the highlight change to indicate the current view in which the user is working.

Perhaps have the default views highlighted with a different colour?

[johnwarburton]

A nice refinement of the Divide commands would be to have the option to place division graphics at the start and at the end of the space that is being divided. It is not allways the case that these graphics already exist and sometimes the division command is used to create drawing graphics rather than just construction lines!