Page 1 of 4

3D editing

Posted: 07 Oct 2014, 17:06
by Zini
Apparently we have people willing to tackle some parts of the 3D editing. I am currently finalising my thoughts on this feature and will post a large brain dump here, as soon as that's ready.

Re: 3D editing

Posted: 07 Oct 2014, 19:15
by psi29a
Will I be able to terraform (heightmap)? Or is this only for cells and assets?

Re: 3D editing

Posted: 07 Oct 2014, 21:24
by Zini
We don't have terrain yet. Little point in thinking about terrain editing without terrain. This will mostly be about objects and the larger picture.

Re: 3D editing

Posted: 08 Oct 2014, 04:26
by Greendogo
Great! I'm glad to see some of this stuff moving forward! :D

Re: 3D editing

Posted: 09 Oct 2014, 13:50
by Zini
Took a bit longer than expected. Anyway, here we go:

We'll start with the general design constrains. First, being minimalistic is important here. We have already a pretty full window and we can't afford to add a lot more elements to it. That's why I introduced this highly compact but somewhat unorthodox toolbar in the scene subview. All further UI elements required in the 3D scene will have to be integrated there.

Second, configurability is important. We will have a lot of different functions that all need to be bound to some kind of input. The user must be able to adapt this mapping to his input hardware. While a 5-button mouse certainly isn't required, the user should be able to take full advantage of it if he has one.
Therefore we won't be talking about physical mouse buttons. Instead the interface will be defined in logical mouse buttons that can then be mapped in the user settings to the physical buttons. Lower button numbers can be compensated either by using modifier keys with mouse buttons (e.g. control) or by mapping buttons to keyboard keys. Mapping to a button to a keyboard-key might be problematic if it is involved in a drag operation. I don't know if Qt would support that properly. That needs to be looked at. If it is too much trouble we might drop it.
On the other hand mapping functions listed here as keys to a mouse button instead should also be allowed.

Current state:
- We use the shift key to perform movement at higher speed.
- The T key switches the input focus between 3D scene and toolbar (which is fully cursor-navigatable)
- Two logical mouse buttons: primary camera movement (bound to left click) and secondary camera movement (bound to ctrl-left click).

For editing we will introduce four new logical buttons:
- primary select
- secondary select
- primary edit
- secondary edit
(more about the individual functions later)

About the separation of edit and select: In the original CS these are the same button. TES-CS decides if a click/drag is selecting/deselecting or moving/changing something by being context-sensitive. And in a dense scene that is a pain in the arse. Admittedly the mouse picking in TES-CS is kinda terrible, but I strongly suspect even with high precision picking we will run into trouble nevertheless.
We must still offer this context sensitive mode for people with less mouse buttons. If the user wishes, he should be allowed to bind both the primary select/primary edit and secondary select/secondary edit to the same button respectively.


Now to the actual editing: We will add a new toolbar button below the current buttons. This button decides about the current editing mode (i.e. what is edited) in the same way as the navigation mode or lighting mode button.

These are the modes we will have:
- objects (references)
- pathgrid
- terrain shape
- terrain texture
- terrain vertex paint
- terrain movement
Depending on which mode is selected the toolbar will add additional button for the respective mode below the edit mode button.

I was originally planning to only speak about the object mode here, because that was the only thing we were rendering. However this morning scrawl sneaked in the implementation for terrain rendering; catching me kinda unprepared. I don't have anything for terrain yet beyond some vague ideas. Sorry. I may come up with something later.


Object editing mode:

This mode will add two buttons:
- selection mode
- grid mode

I don't want to get into the grid mode here, because that is a complex topic on its own (I don't consider the TES-CS implementation any good). We will deal with that later.


The primary edit button will be used to move the selected objects around. The secondary edit button will be used to rotate objects (both through drag-operations).
This should work both when starting the drag on a selected object or not on an object. If the drag starts on an deselected object, instead this should be interpreted as a basic select followed by the edit action determined by the primary/secondary option.


When clicking on an object with the primary select button, the object will become the selection (everything else selected before will be deselected).
When clicking on an object with the secondary select button, the selection state of this object will be inverted without affecting the selection state of other objects.
When clicking on a place that is not an object a drag operation for a selection range will be started (think bounding box selection type from TES-CS). Primary/secondary buttons will work as with direct select.
The type of the select shape will be configured via the selection mode button on the toolbar. The default rectangular shape from TES-CS is an obvious candidate. But we also need at least a spherical one. Maybe we get more ideas for other useful shapes later.

We need the usual "select all" and "clear selection" keys. And the cell marker pop-up menu will include a "select all in cell" item, if in object editing mode.

And of course there needs to be a key to delete the current selection.


Furthermore we need keys to lock movement/rotation to certain axis, similar to the X, Y and Z keys in TES-CS. We have two options here. Either the lock being in effect only while the key is pressed or using the keys as a toggle. In the later case we would add a 3rd toolbar button that can also be used to change the toggle state and shows the toggle state in the main button's icon.
If we want to get fancy, we could add a user settings that lets the user switch between these two modes.


Ideally we also would have a key that will drop the selection to the ground. Or even two keys, one that drops the selected objects to the ground individually and one that drops them as a single shape (maintaining the position of the objects relatively to each other).
However doing that precisely enough may require the integration of bullet physics. Therefore I consider this an advanced feature (required for OpenCS 1.0, but not necessarily for the first iteration of the object editing implementation).


Another important feature is adding objects to the scene. Currently we can do that by dragging a referencable to the 3D scene. That is fine. With the record filter it is easy to turn referencable table into palettes (we may eventually add a variant of the table that shows a pre-view of the object, but that could easily be a post-1.0 feature).
We should add a key that will create an object of the same referecenable that was dragged to the scene last. This will be handy when a large number of objects of the same type needs to be added.

Finally, we need a clone key that makes a copy of the current selection.

The problem with the current implementation is that the new object is placed in a sub-optimal position (0, 0, 0, I believe). We need to find a better approach for that (possibly configurable in the user settings). Also we need an option to make the added object(s) the current selection (definitely configurable in the user settings).


Now we get to the point where things get ugly. Let me iterate some of the important principles here:
- The world data (records) must be modified exclusively through the command-system. This is important to keep the undo-system functional, but also to ensure data integrity.
- Unfinished operations (i.e. a drag that hasn't finished yet) should generally not modify the world data. The respective command must be created only when the operation is finished (the user should also be allowed to press ESC at any time to abort an unfinished drag operation).
- The selection state of the objects is not part of the world data. I would love to make selection changes undo-able, but it would be difficult to support that and I don't have an idea how to do that yet. I guess we could tack it onto the command system, but that has various problems.
- Selection state is specific to a scene subview. You can have two scene subviews of the same location and both can have different objects selected.
- However in-progress changes (i.e. an unfinished drag) should be shown in all sub-views. For example you could have two sub-views that show the same place from different angles. When starting to move an object the movement should be visible in both.
- We will support object filtering in the same way as in the table subviews. The filter toolbar at the top is already there, but it doesn't do anything yet. As a consequence of this two scene subviews of the same place may not even show the same objects.

The problem here is that all this isn't properly supported by the current implementation. Currently each scene subview maintains its own list of objects with their position and orientation and a short description on how to render them.

There are two possible solutions:

1. We move that list to a document-wide storage. In-progress modifications (unfinished drags) would automatically affect all scene subviews. The problems here are a) we would need a separate data structure for handling the selections and b) this doesn't take care of record filtering.

2. We add a class (with a single document-wide instance) between the object lists and the rendering/editing code that uses them. This class would keep track of in-progress changes. Calls that are not about objects affected by in-progress changes would be forwarded to the original lists, while for affected objects the class would provide the modified data.

Not sure which option is better. If I do not get around to implement that myself, the decision will be left to the implementor.

Re: 3D editing

Posted: 09 Oct 2014, 21:11
by onionland
A slight feature I would like to request when it comes to key functionality would be firstly have a key dedicated to temporarily switch to, say, the edit function.
For example say i bind this temporary switch to the space key, that would mean that, whilst I am holding down spacebar, the functionality of the primary and secondary keys would be that of the edit function.
This sort of switch would preferably come for all tools, as well as the typical toggle button most applications have, since implemented once I would assume it to be mostly a copy-paste job, but especially switching between the edit and select tools through this sort of switch would highly useful for reducing overall clunkyness.

Something else regarding key functionality that is not as strictly related to the points Zini brought up would, but also key to usability would be to have certain functions, like zoom in and zoom out, be rebindable for obvious reasons.

Re: 3D editing

Posted: 10 Oct 2014, 10:15
by Zini
A slight feature I would like to request when it comes to key functionality would be firstly have a key dedicated to temporarily switch to, say, the edit function.
For example say i bind this temporary switch to the space key, that would mean that, whilst I am holding down spacebar, the functionality of the primary and secondary keys would be that of the edit function.
This sort of switch would preferably come for all tools, as well as the typical toggle button most applications have, since implemented once I would assume it to be mostly a copy-paste job, but especially switching between the edit and select tools through this sort of switch would highly useful for reducing overall clunkyness.
I am not sure if I understand you correctly. Are you talking about the configuration when select and edit are bound to the same mouse button? Because otherwise there wouldn't be any requirement for switching since we don't have edit and select tools/modes per se.
Maybe having two optional extra keys that (in case of double binding and the resulting contextual operation) can either force edit or select might work. Actually, that is a decent idea.
And of course we will add keyboard shortcuts for all toolbar buttons.
Something else regarding key functionality that is not as strictly related to the points Zini brought up would, but also key to usability would be to have certain functions, like zoom in and zoom out, be rebindable for obvious reasons.
For some camera modes we already have keybindings for zoom. But I guess it wouldn't hurt to add some for the remaining modes. And as mentioned above of course all keys will be rebindable.

Re: 3D editing

Posted: 24 Oct 2014, 22:36
by cc9cii
Zini wrote: Now we get to the point where things get ugly. Let me iterate some of the important principles here:
- The world data (records) must be modified exclusively through the command-system. This is important to keep the undo-system functional, but also to ensure data integrity.
Is there an example of the "command-system" in OpenCS that I can use?

Re: 3D editing

Posted: 25 Oct 2014, 11:20
by Zini
Yeah, like everywhere ?

Look at apps/opencs/model/world/commanddispatcher or apps/opencs/view/world/util.

The idea is basically that you modify world data exclusively by pushing Command objects on the undo stack of the respective document (this automatically executes the command). You can find the available commands in apps/opencs/model/world/commands.

Re: 3D editing

Posted: 25 Oct 2014, 12:12
by cc9cii
Thanks, I'll have a look.