SceneView.txt 4.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899
  1. TODO:
  2. - Core thread gets stuck on shutdown when OpenGL is used...Somewhere in kernel
  3. Weekend:
  4. - Set up grid material and hook it up to renderer (+ actually instantiate it in EditorApplication)
  5. - Fix up shader so I can reference two different gpu vars with a single shader var (e.g. DX11 sampler variables will have different names than DX9 or GL sampler variables)
  6. - You can create a resource handle to invalid resource type. Add a security feature to prevent that, at least in debug mode?
  7. - When unloading unused resources I should do it recursively so it unloads any new ones that might have been released during the first unload
  8. - Ensure that resource handles only have a single mData (and fix Resources::unloadAllUnused)
  9. - Think about picking implementation and possibly Handles implementation
  10. TODO - Think about:
  11. - How will I allow user from C# to draw gizmos and handles?
  12. - Unity uses immediate mode
  13. - I should probably focus more on implementing a nice C# drawing interface so I don't constantly have to go and use C++
  14. - Although this might be overkill for this point - I think even Unitys handles/gizmos are C++ in the end
  15. ----------------------------------------------------------------------
  16. Handles
  17. - Make a few different base handle types:
  18. - Slider 1D (e.g. for movement using an arrow cap)
  19. - Slider 2D (e.g. for movement in 2D using a plane render)
  20. - Similar for scale/rotation handles (see Unity for its implementations of those)
  21. Handles should have colliders which will be queries whenever user input is detected in scene view
  22. If any handle is hit the input will not proceed further (e.g. no picking will be done) and that handle control
  23. will become active.
  24. Base handle types should just be positioned in space and then return value every frame as user moves them.
  25. - This way they can also easily be used from C# for custom user-made stuff
  26. TODO - Think about this
  27. See for inspiration: http://docs.unity3d.com/ScriptReference/Handles.html
  28. ----------------------------------------------------------------------
  29. Picking
  30. TODO - Think about this
  31. Picking
  32. - Create core thread class that accepts a screen coordinate and a camera and it determines object at its position
  33. - System then renders all visible objects with diferent colors
  34. - Image then needs to be read back to determine what was hit
  35. - Result is returned via async op
  36. - Needs to support multi-select where I draw a rectangle on screen
  37. - NOTE: I will also need to render gizmos which I assume will all be within a single buffer. This might require special care since normally I can color each buffer with a different color, which won't work in this case.
  38. - Similar issue might happen with particles and other systems
  39. ----------------------------------------------------------------------
  40. Rendering selection
  41. Get the mesh from the selected Renderable
  42. Draw that same mesh again using a shader that grays out the original
  43. The second mesh will likely need to use depth bias (sloped depth bias too?)
  44. ----------------------------------------------------------------------
  45. Grid
  46. Generate grid of X size around Y point
  47. Normally Y is (0, 0, 0) but we should be able to move it with camera
  48. There will be minor and major axes with slightly different color (and thickness?)
  49. Instead of pixel perfect lines draw 2D quads (Using DrawHelper which has thick line support)
  50. Mesh can be static, I can just move its origin by length of the major line (+ maybe have a fadeout in shader with 1 invisible major line so the movement is not noticeable)
  51. Material is retrieved from builtin materials list
  52. This can be drawn directly using the draw list and not a renderable
  53. ----------------------------------------------------------------------
  54. Gizmos
  55. GizmoSetups
  56. - Determines what to display for a certain component (or a SceneObject) itself
  57. GizmoManager
  58. - Every frame goes through all game objects and create/removes their gizmos. It keeps a cached version of all gizmos
  59. - It keeps a list of gizmo descriptors
  60. - A "diff" of this list is sent to Core thread every frame
  61. GizmosRenderer
  62. - Batches all gizmos into a single buffer and renders them with a single call
  63. - It might be a bit problematic if custom textures are used for gizmos
  64. - Just don't batch those?
  65. When picking GizmosRenderer can draw the gizmos as normal but using a special shader.
  66. --------
  67. Need to allow the user to specify custom gizmos.
  68. - Have a set of methods like Gizmos.DrawSphere, DrawIcon, DrawLine, DrawCube, DrawFrustum, etc.
  69. - Have a CustomGizmo attribute which you can attach to a method
  70. - That method can then call above methods
  71. - Additionally in the attribute you can specify when is the gizmo displayed: Active, Selected, NotSelected, SelectedOrChild
  72. - And an option if gizmo can be picked or not
  73. - These methods will somehow automatically be registered with the GizmoSetups