Feature Requests

From K-3D

Jump to: navigation, search

Overview

We're often asked "why doesn't K-3D do X?" As with all Free Software projects, the answer could be any one of:

  1. We haven't done it yet.
  2. You haven't done it yet.
  3. It's the wrong thing to do.

Keep that in mind as you let loose your wildest flights of fancy.

Multiple undo stacks

This is a general purpose feature that will, for example, allow separation of Camera/Viewport navigation and document's undo stacks.

When modeling, a lot of time is spent navigating the scene, storing camera movements in the global undo stack is wrong : create a view undo tree per camera that stores camera navigation actions only. Adding information, manually moving the camera with the move tool, changing spinners etc, animating/connection properties of the camera are still all part of the document undo system. View undo always affects the active viewports camera, so its impossible to issue the command on a deleted camera. The Front, Back, Top, Bottom, Left, Right views could be implemented in this specialized camera space since they're UI only features.

Extending this idea it would be very powerfull to have a undo stack for every object/module attribute, or rather have a object/module history of the values of the attributes.

Modeling Behavior, Plugins and Features

Things that need to be kept in mind, and of utmost priority for polygon modeling plugins

  • All plugins should request the main selection type they operate on, and if applied to the wrong sort, they should convert to the type requested. This might be better if handled in a generic fashion across the whole application, rather than per plugin. Comments, Tim?
  • Modeling plugins need to be very good about the selection they output. Generally, modeling plugins will be used in succession.
  • In most cases the desired output is a clean mesh that is all quads wherever possible, but possibly contains triangles and n-sided polygons with many more sides. This has a lot to do with that fact that such geometry is generally easier to work with, and also that most people will be using SDS on the surfaces, which works poorly with non quads.
  • Standardized names exist for most modeling operations. They should be used when possible.
  • For many of our functions, Wings3D can provide a very positive reference. It does nearly everything right.

Selection Plugins

  • Select Similar (selects items similar to the current selection, see wings for reference)
  • Shrink Selection. The reverse of Grow selection: deselects points/edges/faces along the border of a selection, i.e. any selected component with one-or-more unselected neighbor. Wings provides excellent reference.
  • Select selection boundary. Selects the boundary(s) of a selection.

Modeling Plugins

  • Slide. Components are moved along their surrounding edges. Refer to wings.
    • Slide Edge
    • Slide Face
  • Extrude
    • Extrude Vertex (Will have the same caveats as those described for the edge extrude...)
    • Extrude Edge. On an open edge this behaves quite differently than on a winged edge. On a winged edge, and edge loop is drawn around the selected edges and the originally selected edges are then moved. For open edges, one new polygon is created, between the orginal selected edges, and a duplication of the original selected edges. These new edges are moved.
  • Duplicate Polygons

Creates a new manifold by duplicating the selected polygons. Should have spinners for offset.

  • Virtual Mirror/Symmettry. A system that lets you model on one side while the other side automatically updates, so that symmetrical objects can be handled easily. Ideally, the resulting mesh should have the center verticies merged, so there is no seam down the middle.
  • Curve tool / freehand polygon tool.

Modeling bugs and features

Multiple objects in property editor

Assuming selected objects are the same type, the property editor should be able to edit them together.


Object history in property editor

  • This sort of goes along with the above... A major problem right now is digging for properties. You can't select a light and just change its intensity. Its intensity won't show in the property editor until you go into the history and find the lightshader properties. This slows down productivity greatly. A solution is easy and obvious.
  • The properties of each node in somethings history should be stacked in the property editor. XSI has this killer feature.
  • It means that if you select a light and a mesh instance, and go to the properties editor, you'll see both there properties. The mesh instance shown in the first section (because it was selected last), and the light properties shown further down.
  • If you select two lights and a mesh instance... you should only see one section for the mesh instance and one section for the lights, (affecting a property in there would affect both lights)
  • It means that too do something like edit a lights intensity, you don't have to dig into the light shader. You can just scroll down, and you'll see the renderman light shaders options.

Animation

  • Keyframes that can be applied to any input
    • Very recommended - a character set based approach to manage keyframes.
  • Custom properties/Attributes, so that users can add spinners in the interface to drive values that scripts work with. Preferably these values would be in the character set.
  • Rotation plane IK solver, should be implemented like 3dsmax and maya, since they work perfectly in there.
  • Bone/skeleton objects, with a ui for setting rotation axis/joint orientation so that they will animate correctly.
    • Easy>>A very fast skeleton deformation system for meshes.(I'm not sure what's out there that we might be able to use for this) with weighting, and a UI that makes it easy to set weights)
    • Hard>>a physically based system for skeleton based deformation of meshes, since weighted vertices are inherently a poor solution. I would imagine a better method is probably quite far in the future, so weighted vertices would probably work for now.
  • An additive morphing system for facial expressions, so that several models can be created, and a character can be deformed by mixing between various combinations of morph targets.
  • Driven keys (keyed relationships between different input/outputs)
  • Constraints for world coordinates' position, rotation, scale, aim/look-at, roll/up-vector (this would be a higher priority if it weren't for the fact that scripts could easily be created to handle this)
  • Weighted animation controllers to mix between constraints and keyframes values. These are a lot simpler than they sound! (this would be a higher priority if it weren't for the fact that scripts could easily be created to handle this)
  • Null objects, with size/drawing controls, so they can be made easy to work with.
  • Interactive pivot point transformations.

Miscellaneous

  • Document mesh XML schema.
  • Fix all known bugs.
  • 100% coverage of undo/redo and tutorial functionality.
  • Revisit the ordering of Undo Tree nodes, and object history nodes, to manage the width of the tree.
  • Filtering / sorting in Object List.
  • Filtering / reordering in Object History.
  • Four-view viewports - top / side / front / perspective.
  • Viewport reference images.

Allow changes in selection mode without converting existing selection

Shift clicking on one of the selection mode buttons should change modes without converting the selection. It will leave the currently selected components selected but also allow the addition of more components, possibly of another type, to the selection.

UI selection mode should match modifier output

UI selection mode should match modifier output There was some small problem that I could "feel" with modeling before, but didn't realize what exactly it was until now.

Here's an explaination, I believe a fix would be pretty easy....

Basically, when you perform an operation that selects things other than the mode you are currently in, k3d needs to change component modes, otherwise its confusing to the user.


As an example. Make a cube. Select an edge. Apply subdivide edge. A vertex is selected! Excellent, its ready to be moved! Push "w"... here's the problem.

The move manipulator doesn't show? Why not? because we aren't in vertex mode. The fact that the move tool doesn't show isn't the problem... the problem is that we aren't put in a mode that corresponds to what is selected.

Also, if a user sees selected verticies on screen, they might want to select more verticies, or unselect some of the ones that are selected. Thus, they will want the select tool to be operating on verticies.

So, when in component mode and a modifier outputs a selection of a certain type, the current mode active on the toolbar should be changed to be that type.

This should clear up a lot of confusion.

It is possible to synchronize the UI selection mode with modifier output in very specific contexts, e.g. when applying the modifier.

Modifiers may produce any combination of selection types, so the UI must be prepared to handle this. Tshead 15:08, 8 Feb 2006 (MST)

Property editor editing multiple nodes

Dealing with materials is currently extremely difficult.

This is primarily because the property editor will only deal with one node at a time. If I select a ton of objects, and apply set material, I am unable to make a change to all of them. If I edit the set material, it just affects one of the objects.

So in order to set materials on lots of objects, I have to do a set material on each one.

The most straightforward thing to do, in my opinion thus far, would be to make it so that if you apply a modifier to a bunch of objects, the property editor would load up all the newly created nodes and would affect all of them.

In that case, the property editor would have to allow editing of multiple nodes at once.

In general, I think if multiple nodes are selected and are of the same type, the property editor should make changes to all the selected nodes.

Anything that is incosistent among nodes should show slightly differently, a cue that the property has multiple state among the various nodes being edited.

Rotating lights is confusing

Rotating lights is confusing : the icons used to represent lights don't show which direction the light is pointing.

It works well in Yafray where each light is a K-3D plugin, but RenderMan shader based ones always have the same representation. Currently, one has to form a sort of arrow and attach it to the light: this way, when rotating the node we can see which way it points.

Maybe add a chooser to adapt light's representation to the current shader.

Unable to work with small objects

Hello all,

I think there must be a better way to work with small objects (i.e. those whose natural scale is in the cm or mm range).

It is difficult to do because: 1/ The input fields have only a 2 digits precision 2/ The near clipping plane cannot be changed and cut the view with large zoom factors

I suggest having at least 3 digits for the input field (or a preference hint somewhere), and an additional near clipping plane position option in the OpenGL options.

A plus might also be to be able to store the unit with the value, and not convert to meters each time, or to have the notion of default unit.

Good work anyway. Christophe

The correct behavior for input fields has been kicked-around before, but there wasn't much of a consensus on how it should work - if you have some thoughts, please add them to the wiki under

http://k3d.sourceforge.net/cgi-bin/wiki/DeveloperDocumentation

To control the near plane, go to the "Camera" object. Main problem here is that manually adjusting the near plane has the effect of zooming, so you either have to manually adjust Left / Right / Top / Bottom, or use Ctrl-MMB-drag to do the same thing. Tshead 15:08, 8 Feb 2006 (MST)

Weld Modifier

"Weld" works in a similar manner to dissolve, where it can be used on edges or verticies.

It is basically like collapsing edges, but it works on vertices. It takes multiple vertices, and make one vertex out of them.

Generally, there is a threshold option also, so that if you have vertices very close to one another (making tiny almost impossible to see thin polygons) they will be collapsed.

For example, suppose you have one object and a similar but mirrored version of that object beside it. One side of a persons face for example, with a mirrored duplicate beside it.

Normally, the artist wants the end result to be seamless, so he needs to weld both sections together.

Theoretically, the verticies should match up with each other in space, so often an artist will select of the verticies on the seam between the two objects, and apply a "weld" modifier. (some programs call it merge instead, but I prefer weld, since merge gets used to describe other functions too).

Weld takes multiple vertices and makes them one. It doesn't just put them in the same place. If faces were between those vertices in topology, they are removed/collapsed so you never get any error prone/non-manifold geometry. One problem in some programs is that the weld verticies function can end up giving you non manifold geometry.

A good weld modifier should not weld things if it would create bad geometry.

Other good options for weld are:

-the ability to only weld pairs of adjacent vertices. (Never three verts into one, just two verts into one at a time. Four verticies would become two.)


A powerful, good weld modifier is one of the several key modeling modifiers that K-3D is still missing, but we do currently havenother modifiers that can be used to work around its absence for now. Eventually we'll need a good weld modifier.

Sew Edges is another one that would be pretty useful. basically just weld two selected open edges.

Automatic saving

In the .k3d folder, have an autoback sub directory, and make k3d save a copy of the scene every couple of minutes into that directory. (Although saving should reset that counter, so if you're constantly saving, it wouldn't have to autobackup.)

You could use a total of 9 files and have k3d cycle between them... the first time it saves as autoback01.k3d file, then it saves autoback02.k3d... etc... until it get to 9, and then it just starts saving over the earlier autobacks. The number of backups to keep and the time between autosaves could be determined by numbers in the options file.

3dsmax uses such a system, and it works extremely well. The only problem with the way max does it is that sometimes, you hit save, and then 3 seconds later, it autosaves, (which is painfully slow in big scenes, to have to repeat the save twice in a row).


Incremental saving

File > Save Incrementally would be a good feature. It works perfectly in wings.

Suppose I save a file called: teddyBear-ModelNumber1094-v001.k3d

The next time I save the file, it should modify the numbers just before the extention, and add 1 to it, so the new file that gets saved next time I use save incrementally is this...

teddyBear-ModelNumber1094-v002.k3d

If no numbers exist it should just tack some on. If I save a file called teddyBear.k3d, and use save incrementally, I should get teddyBear001.k3d.

Orthographic wiews as a property of the Camera

Discussed below:

> About the menu item naming, can 'Toggle projection' > become and "Orthographic projection" that shows > a check beside it when active? > (In general, we don't have to say "toggle" but > rather just show that something is a toggle by > showing a checkbox that indicates its status.) > This would be more consistent with the > orthographic property on the camera, which is a > checkbox, and more easily identifiable. Agreed, but I took the shortest path: it's a lot easier to toggle the projection state than keeping track of focused viewport camera state. Will improve later.

Viewport Navigation: A zoom window tool should exist.


Odds-and-Ends

This is currently fairly unfinished/unorganized. I, Joe Crawford, am making a list of proposals for future versions of k3d, and it needed to go somewhere in the wiki.

Since k3d is already quite functional as a modeling package, I think it makes the most sense to continue focusing on this area of functionality, until we have a leading package in the field. In many ways, we actually aren't that far away from such a goal.

Some of our requirements are new features. Some of what needs to be done is changing existing things, mostly to accomadate better and more intuitive workflow. There are a lot of areas that need major polish, however, before they are easy to use.

Here is a listing of the most necessary features to make k3d a truly excellent modeling package.

Visualization Pipeline: A pipeline UI, where objects can be shown and connections can be made.

Viewport Menus:

  • Shaded Toggle
  • Wireframe on all Toggle
  • Faceted/Smooth toggle
  • Highlights Toggle
  • Hidden Line Toggle
  • Backface Culling Toggle
  • Shade Selected Toggle
  • show safe frame
  • crop viewport to safe frame

Ensure scene has several default camera's for common views Bookmarks system for cameras

Camera undo system

Icons for split panel hor/vert to make it more obvious soft selection, and seletion weighting for modifiers soft selection for

Polygon Information: Heads up display, like in Maya. Should be an option of the Open GL engine.

Object Display:

Visual Feedback for component modes Children of selected object shown in almost white but slightly darker grey to make it obvious which objects are children.

Last object selected shown in slight green tint. (Possibly expand this to the use of several "banks" of selections for use by actions.)


Layers:

Layer properties: Visible, Renderable, Selectable, Wireframe


Context Menu/Toolbars: Commonly modeling tools should always be one click away, and have a hotkey also. Quad Menus and/or better and much more advanced context RMB menus can help accomadate this.

Necessary Modeling Tools:

Create/Append polygon tool Split Polygon Tool Weld Collapse Verts/Edge/Face should all be one command Cleanup/Check geometry modifier, for fixing/eliminating errors

A cursor system like blender, but with orientation and scaling as well snaps vert, curve/edge, surface, grid point Ability to change the manipulator to the cursors axis ability to

Ability of modifiers to use alternate coordinate systems or cursors

Modifier Stack/Tree:

Curve Modeling:

Ability to work with curves and create nurbs objects out of them, and also create polygon objects from them

lathe extrude on curve/axis loft/skin boundary/4 sided

SelectEdgePath Modifier

Takes an input vertex selection and gives the shortest edges path through it as an output selection. Could have two methods for finding paths, option 1, least number of edges, option 2, least distance along edges. This feature is called Path Select is Blender. It is extremely useful, especially when select edges loops is insufficient. From the Blender docs "In vertex mode, 'Path Select' will find the shortest path between the last 2 vertices selected. There are two methods for determining the shortest path, one that finds the path with shortest physical distance, and one that finds the path with shortest topological distance."


UV Mapping

UVW Mapping system. Should work mostly in the front view, but be 3D viewports where you can rotate faces around edges in 3D to unfold them.

Have a cylindrical/hose mapping option that maps faces around a curves.

Have a projection system that uses the UVs of one object and projects them onto another. Ie, use a simple grid with 0 to 1 UVs, wrap it around another object and use project. Max can do this with its Nurbs surfaces, and project their mapping onto polygons. Its really amazing.

LSCM mapping... the code for this is open and accessible. Both Wings3D and Blender has good LSCM mapping systems.

Vertex Edge Face Mode

Vertex Edge Face mode is a selection mode. Double clicking on an object when in object mode should go to vertex/edge/face mode.

Vertex edge face mode is very short lived. Once something is selected, it is exiting and a specific mode is entered into.

In vertex edge face mode, any type of component of the selected object can be selected. When the first item is selected, the mode switchs to selecting only components of that same type.

For example if the user clicks on a vertex, that vertex is selected, and the selection mode goes to vertex mode.

If a edge is selected first, the selection mode goes to edge mode.

Highlighting Selections

When moving the mouse across objects in the viewport, things become highlighted when the mouse moves over or near them. This provides the user with a visual way to know what will get selected.

Wings3D handles this perfectly, and even features a HighlightedTemporarySelection which makes it easier to operate on things without clicking on them.

This feature would work well with Vertex Edge Face Mode. One of the fastest ways to speed up mesh interaction.

Temporary Selections

The "highlighted temporary selection" is based on the concept that when nothing is selected, whatever is highLighted is treated as the selection.

Until we have an implementation of highlighting in real time, we should simply check which thing the cursor is over on the mouse click or drag. (As of May 31st 2005, that is how we currently work.) The highlighted temporary selection can be used this way for RMB features until a complete wings3d style highlighted temporary selection is implemented.

Versitile Layout

One of the best and most impressive features about Modo is the highly configurable user interface. Instead of using the layout menu and choosing things like split horizontally and split vertically in K-3D, it is all done by grabbing panels with the mouse and dragging to a new spot on the screen. it will automatically do things such as split the panels vertically or horizontally depending on where you drag the mouse to.

We already have all the underlying inner workings functional as far as panel layout goes in k3d. it seems that at some point in the future, it would be easy enough to work in something similar to Modo's functionality. Not something to do right away, but another thing that would be very useful down the line.

They also use a similar "layout" menu, and have loading and saving of bookmarked layouts. They also make it very easy to swap between layouts, Blender style.

Context Menu Additions

The transform sub menu should have another sub menu listing.

  • point
  • line
  • face
  • object
  • ...

These menus should then list

  • Orientation
  • Translate
  • Scale
  • ...

Where there is not a plugin, e.g. Translate Face/s a macro is all that is require, i.e. change the selection to point mode then call translate points.

All the point (vertex) warpers should be applicable to edges and faces in this manner too.

Adding the view change menu to the right click would be handy too 

 Change View
      Prespective
              +x
              -X
              +y
              -y
              +z
              -Z
              Light(Name)
              ...
              Camera(Name)
              ...
              Push User Current View on View History
              Pop User View off View History
              Copy User View off View History
      Orthographic
              +x
              -X
              +y
              -y
              +z
              -Z
              Light(Name)
              ...
              Camera(Name)
              ...
              Push Current View on View History
              Pop View off View History
              Copy View from View History


NB the difference between Copy view... and Pop view

Retrieved from "http://wiki.k-3d.org/Feature_Requests"