Runtime Level Design

Hi everyone,

This is the official forum for the Runtime Level Design (RLD) pack. RLD is a Unity plugin that contains powerful level design tools that can be used at runtime. Incredibly handy if you need to build a runtime editor or a game that contains level design elements.

Presentation video:

Jump right in an learn how to build a dungeon:

Many more video tutorials can be found here.
API Docs are available here.

Cheers,
Andrew

 

Hi everybody,

Version 1.1.6 is now live on the Store. Here is the list of improvements and bug fixes:

Improvements:

1. it is no longer necessary to attach colliders to game objects. The system can now interact with 3D and 2D objects even if no colliders are present;
   
2. 2D sprites can now be selected correctly even if they do not reside totally inside the XY plane;
   
3. the selection box scale factor has been transformed into an offset (value which is added instead of multiplied). This was necessary because a scale factor will produce inconsistent results for objects of different sizes;
   
4. it is now possible to specify if lights, particle systems, empty objects or sprites can be selected;
   
5. improved performance for visible object determination. This data was necessary in some situations (such as when selecting objects with the selection rectangle) and it is now cached and only updated when necessary;
   
6. it is now possible to specify if the object selection boxes can be drawn. This can be controlled from the EditorObjectSelection Inspector or from script: EditorObjectSelection.Instance.ObjectSelectionSettings.ObjectSelectionBoxRenderSettings.DrawBoxes = desiredValue;
   
7. the application no longer acquires the vertex snapping data at startup. For larger scenes, this can lead to big load times. The system now acquires the vertex snapping data only when it is needed. The algorithm used to calculate this data has also been improved (e.g. the floor object from the Survival Shooter Unity package was taking around 16 seconds to have this data calculated. Now it is computed almost instantly);

Bug fixes:

1. fixed bug which was causing selection boxes to be rendered incorrectly for terrain objects;
   
2. fixed bug which was preventing the selection system to work correctly after using the move gizmo's terrain surface placement functionality (i.e. the selection system would become disabled);

 

Hi everybody,

Version 1.1.7 is now live on the Unity Asset Store. Below, you can find all features/improvements and bug fixes that have been made:

New features:

1. scene gizmo (no smooth perspective switch; the switch is done instantly);
2. surface placement and axis alignment for mesh surfaces for the move gizmo;
3. axis masks for all gizmos (please see the 'SetObjectAxisMask' and 'SetObjectAxisMask' in 'Gizmo.cs'). When an axis is masked, the gizmo will not be able to transform an object using that axis. For example, for a rotation gizmo, when an axis is masked for an object, the object can not be rotated around that axis. Same for the other gizmos;
4. it is now possible to specify if a selection rectangle can be used for object selection. You can use the Can Multi-Select' toggle button inside the EditorObjectSelection Inspector to toggle the selection rectangle;

Bug fixes:

1. fixed null ref exceptions thrown when switching between scenes;
2. fixed bug which was causing inactive objects to get selected;
3. fixed gizmo position not calculated correctly when first object was selected;
4. fixed grid was being rendered by all cameras which were active in the scene. Now, only the editor camera is used to render the grid;
5. fixed camera background flicker (could sometimes happen when quickly moving and/or rotating the camera or when focusing the camera on a large group of objects in ortho mode);

 

Hi,

Great asset, but I think it would be even better if the forced camera controls and undo-redo system were optional. Right now I cannot use this asset because it interferes with my own camera, shortcut keys and undo-redo system.

 

Hi there SunnySunshine,

I remember I solved the same problem for you in the past quite some time ago (more exactly 5th of February 2016) and I sent you the package without all the other systems in place. So I do not understand the reason why you wrote this message here. If you lost the package, I can send it to you again.

Best Regards,
Andrew

 

Thanks for the fast reply.

Yeah, I just started a new project, and while I do still have that package you sent me lying around somewhere, I just think it would be neat if this asset actually supported these things by default. I'd feel a lot more comfortable downloading assets from the asset store that I know have been adapted to the latest versions of Unity rather than using some package that is nearly a year old (and even older as time goes by). A lot of people use their own camera rigs so I think the feedback is valid.

Btw, another thing I noticed is that the angle snapping is a bit unorthodox in this asset. When you start dragging normally (without snapping) and then enable it (by pressing control), the snapping will occur according to when ctrl was started being pressed rather than according to it's original orientation when drag was initiated. That's not how snapping usually works in 3D authoring software.

 

A... I understand. You would like to use the most recent version of the package. Makes perfect sense Well, regarding the camera, you can easily do that by disabling the EditorCamera script and attaching your own script on the camera. The only thing to keep in mind is that it has to be the same camera object that is created when you initialize the system.

Regarding snapping, I will look into it and see what can be done.

My fault with the name, sorry about that. I honestly didn't think it would cause any trouble

 

That's the thing though. It's pretty big to assume the user only wants to use that specific camera. There are so many different systems, and imo objects should be selectable and the gizmos usable regardless of what camera is used.

I may be wrong here, but I think the main thing people want when buying this asset are the gizmos. These other systems should be addons to them, not mandatory components that are automatically added even when disabled.

Shortcut keys should be possible to disable, or at least tweak, and the actions these keys execute should be available programmatically without having to edit your source code. Undo-redo should be optional as well.

I sent you a PM with some other suggestions.

 

And it works awfully. You gave no option to stay with simple collider system. Tragically inefficient.

Hint: Image game object with collider only without mesh which acts as a group for children models.

 

Hi there,

I am sorry to hear you experienced problems. I understand the example you provided, but have you actually experienced any slowdown?
In any case, this option will be available in the next update.

EDIT: Part of the reason why this system was implemented was to allow 2D sprite objects to be selected correctly. 2D colliders did not work well with the selection mechansim. I do not remember the exact issue, but I needed this for multi-selection.

Thanks for the hint!

 

Sorry XGT08, no hard feelings. I simply updated library because i wanted some of functionality and API change was so big I spent whole day to merge things in project to find out that performance dropped 2-3 times.

I will send PM to you with pointing where and why I have these drops.

 

No problem I sent you a PM in response.

 

Hi there!

I'm interested in purchasing your product.

My main use would be to tweak objects while actually playing the game, so I'd like new instances, new positions, new scaling to be kept while returning to the editor.

Is this possible to do out of the box, or do I have to code it myself? Are you providing another asset to do some runtime permanent changes to the scene?

Thanks for your time.

 

Hi there @NeatWolf ,

EDIT: Wow. I initially thought you were talking about another package (I mixed the forums up ) and my initial answer was related to that instead. So to rectify, at the moment this is not possible, but if you give me some time, I will try to do it. One note from me is that the way I can see this implemented is that it will require you to attach a special script to all objects that you wish to have their info persist. Would that be acceptable to you?

Best regards,
Andrew

 

Hi, I believe so, thanks, but I still haven't even got the asset

But I'm still a bit confused about what exactly the asset (and Runtime Widgets, and Octave3D) does.

By Runtime you mean, in the Game View, or runtime as per in a complete build?
Could you please compare your products? There are a few parts that seem to overlap.

 

Hi there,

Ok, so here's a short summary for all packages:

• Runtime Transform Gizmos - allows you to use transform gizmos (like the ones inside the Unity Editor) either in the Game view (while in play mode) or in a build to move, rotate and scale objects. The idea is that you sometimes may need to build an application (or game) that requires object manipulation at runtime (build or game view). Unity has an API for allowing you to work with gizmos but only inside the actual Editor environment and they are useful when building Editor extensions. This package also contains some bonus features like a camera, object selection and Undo/Redo. Currently, these are all coupled and must be used together (except for the camera which can be replaced with a few constraints). I am trying to decouple the systems to make them work independently as much as possible. Still in work.
  
• Runtime Widgets - same as the previous package, but this package gives you access to those visual widgets that you see when editing colliders, lights etc inside the Unity Editor. For example, if you have a box collider in a Unity scene and click on Edit Collider in the Inspector, a visual representation (I call it a widget) will appear which can be used to alter the box collider size. Again, it can run inside the Game view or inside a build. A package like this might be useful if you were implementing an Editor-like application which allows the users to change properties for different colliders, lights, reverb zones, controllers etc. This package also comes with an Undo/Redo system. This package does not require 'Runtime Transform Gizmos' although the 2 can be integrated to work together. There is a chapter in the Runtime Widgets documentation about how the 2 Runtime packages can be integrated, but this will change when the system coupling in Runtime Transform Gizmos will be removed. In that case the integration might require developers to write a bit more code, but it would be more flexible.
  
• Octave3D - this is a powerful level design which runs entirely inside the Unity Editor (no game view or build). Contains snapping functionality ideal for working with modular pieces, mesh spawning/painting, a prefab management system and many many more features.

You probably mean Runtime Transform Gizmos and Runtime Widgets. Octave3D doesn't have anything in common with these 2. The overlapping has to do with the fact that they both implement functionality which exist inside the Unity Editor but allows developers to use that functionality at runtime (build or game view).

I hope this helps, but please let me know if you need more info.

 

Thanks!

I think I may need more Octave3D than Runtime Transform Gizmos (of course, everyone has its needs, I may eventually need all 3 assets in the future )
My only reason to buy Runtime Transform Gizmos would be for the unimplemented feature of making object "stick" to their changes when switching back to the Editor from Play Mode.
That would be really helpful when you need to do a lot of fine-positioning of objects but you also want to see it how it looks in game with all its features running (PostFX, camera settings, being able to determine the distance of a platform and tweak it in at play time, fixing wall holes, spotting glitches, checking for actual positions of the objects according to the player's view and logic, checking for distances, eg: decorating a house)

 

Great!

I guess when you talk about changes, you mean position, rotation and scale, right?
Well since I am already working on an update for Runtime Transform Gizmos, I can try to implement that feature. I think it will work. Just please allow me some time, I guess 2 or 3 days to fully be able to come up with a stable solution. I don't want to make any promises that I can't keep But my guess is that it will work as long as you can live with the fact that you will have to attach a script to the objects which you would like to persist.

I will keep you updated on this

EDIT: Strangely enough, Runtime Widgets allows you to preserve the changes made to colliders, lights etc via the widgets in Game view. I do not know why I didn't think of this for Runtime Transform Gizmos also. So this is a great idea and I would like to thank you for it

 

Position, rotation, scale, and maybe duplication, deletion and group selection/manipulation
Attaching a script manually on every object in a scene that *could* be modified sounds very unpractical and time costly. What about centralizing the changes on a single object, or instantiating such components at runtime as soon as an object gets modified, passing the extra info structure (scale, position, location, bool pendingDestroy, GameObject pendingCreate) to be preserved to a PlayModeChangesManager (which basically keeps a collection PlayModeChangeInfo) just before exiting Play mode? This way all these helper components would be destroyed when returning to Edit mode and no further cleanup would be needed

It was just an idea, but you're welcome, I think this could be a great addition to Runtime Transform Gizmos, or even an idea for another asset
I'll be watching this thread so that I can follow its updates

 

Hi there @NeatWolf

I can understand how the component solution may not be the best out there. I will try to come up with something else. I think you are right in that the changes for an object can be centralized. I will have to see how this fits with the current code base.

One thing to note is that I'm afraid I can not help with the following: duplication, deletion and selection. Selection is something that exists at runtime only, it doesn't affect the selection in the Editor. As for the rest, I believe these require knowledge of serialization techniques which for the moment I do not have So what I can do is to preserve the position, rotation and scale of the objects.

 

I wasn't very clear: when I talked about selection I only meant that the user should be able to use selection and multiselection in play mode, it was not a thing I wanted to keep when switching back to the editor

About creation and deletion, I was thinking/suggesting about a more naive approach:

Each object that gets manipulated in realtime creates a struct/class like this on the object, or on a generic list of PlayTimeInfo:

Code (CSharp):

1.  
2. PlayTimeInfo{
3. GameObject manipulatedObject; //null if this object has been created during playTime, otherwise this holds the reference to the actual object which has been manipulated
4. Vector3 localPosition;
5. Quaternion/Vector3 localRotation;
6. Vector3 localScale;
7. bool pendingDelete=false; // Should we delete this object when returning to the Editor?
8. GameObject pendingCreationObject=null; //If null, just apply the changes. If not null, first instantiate this GameObject and then apply the above settings on that
9. }
10.  

supposing we are able to keep this data about every manipulated object when going back to the editor, we apply all changes to objects that have the manipulatedObject == null or the pendingCreationObject != null.
if pendingCreationObject is not null, we instantiate in editor an object with pendingCreationObject as "Prefab"
we then apply all transforms.
finally, if pendingDelete == true we delete the manipulatedObject object (or, we may be entirely skipping its creation/tweaking)

During playtime:
Deleting an object = setting an appropriate PlayTimeInfo with a reference to the object about to be deleted, and pendingDelete = true

Duplicating:
if pendingCreationObject != null, then it's a duplicated/new object

Duplicating an existing object = setting an appropriate PlayTimeInfo with a reference to the object about to be instantiated in pendingCreationObject

Duplicating a duplicate = duplicate the PlayTimeInfo, also copying the pendingCreationObject since they're both created with the same blueprint.


Of course the new objects are not really the same (different instanceID) when going back to the editor, but since we're probably just decorating, it shouldn't matter.

The only important thing is to handle creations before deletions.

This is just how I'd try to implement it, there are probably more stylish ways to do it
No need to know about any serialization technique

 

Sorry for the late reply.
Ok I will give this a try and let you know how it worked.

 

Hi @NeatWolf ,

Unfortunately I haven't managed to start working on the solution yet. I am working on an update for another package and I thought it would be finished by now, but it seems to take more time. Is the needed functionality urgent? Although I wish to finish with the other one, I can make a switch if needed.

Thanks for undestanding.

 

Hi,

thanks for caring but no, it's not urgent, it would be a welcome feature to have, tho

Please keep us posted about it!

Cheers,
Alessandro Salvati

 

Hey there,

I can't seem to find it anywhere - what's the licensing on this? Per seat? Per Title?

 

Hi,

I am sorry, but to be honest, I can not give you a direct answer to that since it's not really my area of expertise
The best I can do is to point you to this page: Legal Terms. I believe Appendix 2 contains the info you requested. In any case, you should be able to get a much clearer answer from a Unity representative.

Thanks for taking an interest in my package.

 

No worries, lad. Just trying to determine if I need to pay per user or if it's a one-time purchase.

The legal terms link pretty much answers my questions. Thanks for the heads up!

 

Ok. Glad to hear you cleared the matter up!

 

Hi there @NeatWolf

I just wanted to let you know that I haven't forgotten about you
I have released a new update for RTTGizmos recently and I've just finished implementing another one. Need to submit it on the store and I think I can start working on the functionality that you requested tomorrow.

Thanks for your patience

 

Since in the description of the asset is not reported is a one-time

Great to know! I also haven't forgotten about you as well, since I came here several hours ago to check up the current state of the asset (notifications aren't working properly) and finally decided to purchase it with or without my feature requests
Looking forward to the next update then!

Cheers,
Alessandro Salvati

 

@NeatWolf
Ok. Great! If you would like me to send you the package before it gets approved, send me an e-mail or PM.

EDIT: This package won't contain the features you requested. That will be in the next one

 

HI everyone,

I would like to let you know that version 1.2 is available on the store. Here are the new changes:

New features:

1. added event for active gizmo type change (e.g. EditorGizmoSystem.Instance.ActiveGizmoTypeChanged += EventHandler);
2. added IRTEditorEventListener interface which can be implemented by monobehaviours to listen to different types of events;
3. it is now possible to specify the corner where the scene gizmo will sit. Possible values are: TopLeft, TopRight, BottomRight, BottomLeft;
4. key mappings for gizmos, object selection and camera;
5. it is now possible to specify if Unity colliders must be used for object interaction. This is especially useful when you are working with scenes that contain large amounts of objects or when the meshes that you are working with are very high res. If you experience low frame rates, checking the 'Use Unity Colliders' options in the RuntimeEditorApplication Inspector should fix this issue. NOTE: Using Unity colliders is not possible when working with 2D sprites. In that case, the custom system must be used (i.e. uncheck Use Unity Colliders).

Bug fixes:

1. fixed terrain and mesh surface placement for move gizmo bug which was happening when the controlled object was part of a hierarchy. The objects would snap in an awkward manner because the mouse cursor was hovering one of the objects in the hierarchy;
2. fixed gizmo position not updated correctly after gizmos were toggled off;
3. fixed rotation gizmo angle snap not working correctly when activating snapping in the middle of a normal rotation session. The gizmo was applying the snap rotation relative to the existing rotation instead of the default pose (zero rotation).

Removed:

1. the scene view gizmo representation for the transform gizmos is no longer shown. This was done purely for having a cleaner and smaller codebase as far as the gizmo classes are concerned. Besides, the scene view representation was rather rough around the edges and it is much more useful to check the look and feel of the gizmos at runtime, in the environment where they will actually be used;
2. SetEnabled method from the EditorObjectSelection mono. Enabling or disabling the object selection mechanism can be done by simply enabling or disabling the EditorObjectSelection component;
3. ObjectSelectionModeChangedAction is no longer available. The reason that this action existed was to ensure proper undo/redo of this mode change. However, this is useless and error prone. The ObjectSelectionModeChangedMessage has also been removed;
4. AssignObjectsToSelectionMaskAction is no longer available;
5. RemoveObjectsFromSelectionMaskAction is no longer available;
6. removed custom object selection click/multi select handlers. In consequence the 'Custom' object selection mode has also been removed;
7. removed gizmo change, transform pivot change, transform space change and turn off gizmos actions. These were necessary to allow Undo/Redo for these types of proprty changes. However, Undo/Redo is no longer supported for these as it can prove to be rather unintuitive;
8. the 'TakeZoomFactorIntoAccount' property of the editor camera has been removed. This should always be the default behaviour;
9. removed 'ObjectsAddedToSelectionMaskMessage' message class;
10. removed 'ObjectsRemovedFromSelectionMaskMessage' message class;
11. removed 'TransformSpaceChangedMessage' message class;
12. removed 'GizmosTurnedOffMessage' message class;
13. removed 'TransformPivotPointChangedMessage' message class;
14. removed 'ActiveGizmoTypeChangedMessage' message class;
15. removed redundant gizmo color properties which could easily be deduced from the specified gizmo axes colors.
    

As you can see, there's quite a number of things which have been removed , so please be aware that if you have been using these entities (classes or functions) in your project, you might get compile errors when importing this new version. However, I consider that this was a necessary cleanup so it had to be done.

I would like to suggest that you take a look at the entire chapter 6 inside the documentation as there are some new things that you can now do with the API which weren't previously available.

Please don't hesitate to contact me for any inquiries you might have.

Enjoy!

Best Regards,
Andrew

 

Hi @NeatWolf ,

I just wanted to let you know that as of this moment I can start working on the functionality you requested. I will keep you posted

 

Hi @NeatWolf ,

I wanted to let you know that the requested functionality is finished.
You can preserve object position, rotation and scale, and object duplication. However, you can not record object deletion. The reason for this is that the system currently does not support a feature which deletes objects. Although it may seem simple, it is made a bit complicated by the fact that it also has to work with Undo/Redo.

Also, please keep in mind that all the changes (position, rotation, scale, object duplication) must be performed via the RTTGizmos interface (no Unity actions). This is necessary because the system needs to be informed when such events occur.

Let me know if you would like me to send you the package (PM or e-mail).

 

Hi everyone,

Version 1.2.1 is now available on the store. Here's the change list:

New features:

1. added 'Can Click-Select' property in object selection Inspector. If unchecked, the user can no longer select/deselect objects by clicking;
   
2. implemented new scale gizmo type called 'VolumeScaleGizmo'. This allows you to perform object scaling in almost the same way that you can modify box colliders using collider widgets;

Improvements:

1. added possibility to toggle the Undo/Redo system on/off ('Enable Undo/Redo' toggle inside the Runtime Editor Application Inspector);
   
2. added possibility to specify if a custom camera must be used for scene navigation. When a custom camera is used, default camera functionality is disabled;

Bug fixes:

1. fixed bug which was causing the active gizmo type to change when manipulating the camera (happened because of hotkey clash);
   
2. fixed scene gizmo was not taking the editor camera viewport into account.

You can see the volume scale gizmo in action in the following video:

Enjoy!

 

Finding a number of bugs in 1.2.1

First one, in MonoSingletonBase.cs:

public static T Instance
{
get
{
// Is the instance availanle?
if (_instance == null)
{
// Apply lock on our sync object
lock (_singletonLock)
{
// Retrieve the instance from the scene.
// Note: We will retrieve an array of instances and make sure that only one intance exists.
T[] singletonInstances = FindObjectsOfType(typeof(T)) as T[];

// More than one singleton?
if (singletonInstances.Length > 1)
{
// Log warning message if running in editor mode and then return null
if (Application.isEditor) Debug.LogWarning("MonoSingleton<T>.Instance: Only 1 singleton instance can exist in the scene. Null will be returned.");
return null;
}
_instance = singletonInstances[0]; // Only one instance was found, so we can store it
}
}

// Return the singleton instance
return _instance;
}

First pass through, on line `_instance = singletonInstances[0];` will throw a system exception that you are going out of bounds on the array, since the array isn't created.​

 

Starting with V1.2.1 the singleton class assumes that the instances already exist. They are created when you click on the Initialize menu item. In previous versions, they were created by actually calling the Instance property which would detect that no instances exist and it would create one.

So FindObjectsOfType will always return an instance except for the case in which we are dealing with the UndoRedoSystem which can now indeed be missing from the scene in case it was disabled in the RuntimeEditorApplication Inspector. However, even in this case, this is treated elsewhere so currently there is no danger here.

But this is indeed something that needs to be adjusted. The length of the array needs to be checked against 0 and if it is 0, return null.

I will fix this in the upcoming version.

 

Yeah, I'm using it a bit differently - invoking and building the runtime components through code, not through the Editor initialization script - would rather build it at runtime rather than storing gameobjects into the editor.

I've also noticed that there are an number of additions of `#if UNITY_EDITOR` that are defined in source files in the `Scripts` folder, rather than isolating them inside the `Editor` folder. Personally, I prefer that separation.

 

Well, I built the singleton class and classes that derive from it with the assumption that they will always exist in the Editor after Initialize was clicked on .

Regarding, #if UNITY_EDITOR that all depends on someone's style I guess. In this case I do not remember where these are used, but I usually like to have only GUI related code in the Editor folder. If other types of functionality require to run only inside the Editor, I will use the macro wherever I need to. For example, in the GameObjectExtensions file (if I am not mistaken) I used this macro to include the UnityEditor namespace and to define a function which checks if an object is a scene object or a prefab. This file resides somewhere in the scripts folder.

Also sometimes (but I believe it's not the case in RTTGizmos), I might have a Settings class for a specific entity and I would define a method called RenderView() to render the GUI controls inside the Inspector or Editor window that allow the settings properties to change. In this case, I would have to use the macro and only compile the RenderView method when inside the editor. Puting the Settings class inside the Editor folder won't work because then I would not be able to access it from the Scripts folder.

Well.. I guess there is no right or wrong here. If you need any help with the scripts, let me know.

 

Would it be hard to modify your runtime gizmos to work with VR, raycast from the tracker to select gizmos and move them?

 

I wanted to start off by saying this is an awesome system! I had a home-brewed gizmo system for my in-game editor but this gives it a much more professional appearance and feel.

There are a few requests that I think would make workflow much easier for some of us.

1. Could you add functions to add and remove a single GameObject from selection? Currently we must take a list of selected objects, add or remove the objects, and use SetSelectedObjects to apply that list.

2. Masking certain axes masked will disable the ability to use them, and that's great. However, objects are still allowed to be manipulated along the disabled axis. For instance, if you disable the X axis for the rotation gizmo but click on the inner sphere, you can still rotate every direction. I would like to see the "mask" feature also disable object manipulation along that axis. It would be nice as well if the masked axis wasn't even drawn.

3. The current system doesn't work well with objects that have multiple colliders and meshes set as children of a root object. Clicking a mesh/collider selects the child object instead of the root. I understand there is the "Entire Hierarchy" selection mode, but that doesn't work if you're working with larger nests of objects. I created a script that will change the selectioned object to something else.

Code (CSharp):

1.     public void OnSelected(ObjectSelectEventArgs selectEventArgs) {
2.         var selection = EditorObjectSelection.Instance.SelectedGameObjects;
3.         selection.Remove(gameObject);
4.         selection.Add(gameObjectToSelect);
5.         EditorObjectSelection.Instance.SetSelectedObjects(selection.ToList(), false);
6.     }

However, that method is quite slow when using multi-select as the object is "selected" simply by being dragged over with the selection rectangle. Having built in support for deferring selections to a specified GameObject would be very helpful! Or, if ObjectSelectActionType had an enum case for being selected by the currently active selection rectangle and then MultiSelect when the mouse button is actually released, that would make my code work much better.

Thanks for the great plugin! It's saved me so much time already and with some tweaks I think it'll be even better!

 

Hi there Lennart,

To be perfectly honest, I have absolutely 0 experience with VR, so I can not give you an exact answer because I do not know what the implications are. However, I can tell you that raycasting and everything that is needed to interact with the gizmos resides in a specialized class called InputDevice which essentially is a wrapper for mouse and touch devices (Note: Although the package works with mobile, mobile support is not yet officially available).

If you wish, I can send you the InputDevice script file and you can take a look over it and decide if it can be modified for VR easily. Just PM me and I will send you the link and if you have any questions, please let me know.

Thanks for contacting me!

 

Hi @MastaC ,

Thanks for the kind words I am glad you like the package!

Now let's talk about the points you mentioned:

1. I believe it can be done. To be honest, I do not know why I did not do that from the beginning
2. All gizmos have what I like to call 'special ops' To follow your rotation gizmo example, clicking and dragging the inner sphere is a special op and when you perform that kind of rotation, the rotation is not applied along the gizmo axes, but rather around the camera axes. So when dragging the sphere, the rotation will happen around the camera local X and Y axes. When dragging the screen circle which surrounds the rotation gizmo, the rotation happens around the camera look (view) axis. Same rules apply for other gizmos. For example, for a move gizmo, when you hold down LSHIFT, a square will appear which lets you translate the objects along the camera right and up axes. Axes masks refer only to the X, Y and Z gizmo axes (move gizmo axes with cones, rotation gizmo circles - the red, blue and green ones, scale gizmo axes with boxes). This was always the intended behaviour. The main reason why I chose to do it this way is because I simply find it more intuitive this way. If you picture a move gizmo for example in your mind and I come to you and say out loud: X, Y ,Z! I am pretty sure you will think of the gizmo axes with the cones at their tips. Now if you need a different behaviour, I may be able to come up with a custom solution, but this behaviour will never be part of an official update I hope you understand. As for why the gizmo axes are still visible when masked, that pretty much has to do with the fact that axes masks are applied per object. So if you have a group of objects, some of them masked for the X axis, others not masked, then what should the gizmo do in that case? Of course, I could just program the gizmo to automatically hide/unhide its axes based on the object selection, but for some reason I didn't think of that . However, there is an update pending review which allows you to hide individual axes for different gizmos either from the Inspector or from code. This was suggested to me by somebody (outside of gizmo axes masks). And I think it offers more flexibility. For example, you could intercept the selection changed event and based on the current selection decide what axes should be hidden or not. Send me a PM if you wish to have access to the package earlier.
   
3. I think I know what you mean, but I think I need more details. So what I did manage to understand is that, you would like to select down from the root. So if you click on object A, select A and all its children. Is this the desired behaviour?

Thanks for contacting me!

 

@XGT08 Thanks for the quick reply!

For #2 I can see how there would be so many edge cases, and leaving the gizmos how they are would probably be the best thing. I tapped into the listener interface and used OnAlteredByTransformGizmo(Gizmo gizmo) to cancel out the axes I want to freeze, and that worked out perfectly.

For #3, here's an image to show what I mean! Just for clarification, I'm using the "Use Unity Colliders" option.



I click one of the Mesh and Collider objects, and the editor will select that individual object. Then I act on it with the gizmo and it'll move the Mesh and Collider object only, leaving the Root Object at the same position. What I want is when I click any of the "Mesh and Collider" objects it will defer that selection to the "Enemy Root Object" allowing me to act on the entire enemy.

The script I posted in my last post is added to all Mesh and Collider GameObjects and will select the correct higher level object when clicking or multi-selecting. It's not very efficient because I believe it triggers every draw call, due to the object becoming selected as soon as you drag the selection rectangle around it.

I hope that better clarifies my issue! Thanks!

 

Hello everyone,

Just wanted to share a quick note with you. So starting with version 1.2.3 (1.2.2 is currently pending review), the object selection modes (IndividualObjects and EntireHierarchy) WILL BE REMOVED. The reason for this is because the IRTEditorEventListener interface gives you the power to manipulate the selection in any way you wish (select individual objects, select entire hierarchy, select to bottom etc). There is just no need for these 2 modes anymore.

The API will expose some methods that will help you retrieve objects from a hierarchy in different ways that will help you filter the objects as you wish (e.g: GameObjectExtensions.GetAllChildrenIncludingSelf, GameObjectExtensions.GetAllRootsAndChildren(objectCollection).

The documentation will explain how to use these and how to achieve different desired effects.

@MastaC
Hi there,

I have implemented 2 functions which allows you to Add and Remove objects to/from the selection. This seems to solve the problem you had. I constructed a cube hierarchy and I have been able to delegate the selection to the top level object (I chose the top level one, but it could have been any other object). Care must be taken to avoid entering an infinite recursive loop. So make sure that you always have some sort of stop condition in the selection handlers. In my case, I had to check if the object which was selected wasn't already the root which I was interested in:


Send me a PM when you read this so that I can send you the updated package.

Best Regards,
Andrew

 

Hi there everyone,

I would like to let you know that version 1.2.2 has been released. Here is the change list:

New features:

1. it is now possible to control the visibility of different gizmo axes (see 'Show X Axis', 'Show Y Axis', 'Show Z Axis'' toggles in the gizmo Inspector GUI. The visibility of the rotation sphere for the rotation gizmo can now also be toggled on/off. Components which are not visible will not be rendered and can not be interacted with.

Bug fixes:

1. fixed bug which was generating script compile errors during build;
2. fixed bug which was causing the volume scale gizmo to miss sending a drag end message after a drag session was finished;
3. fixed bug which was causing objects to incorrectly change their position when scaling them using the volume scale gizmo. This was happening when the object had a negative scale along the scaling axis;
4. fixed bug which could potentially throw an index out of bounds exception inside the MonoSingletonBase class;

Version 1.2.3 has been submitted for review so it's on the way. More info soon.

All the best,
Andrew

 

Hi everyone,

Just wanted to let you know that V 1.2.3 is now on the store and it contains the following changes:

New features:

1. implemented 'AddObjectToSelection' and 'RemoveObjectFromSelection' to add object to or remove them from the object selection;
   
2. it is now possible to specify how the object selection boxes are rendered (PerObject, FromParentToBottom).

Removed:

1. removed the 2 selection modes (IndividualObjects and EntireHierarchy). The same behaviours ca be implemented using the IRTEditorEventListener interface.

Bug fixes:

1. fixed bug which was ignoring Unity colliders when 'Use Unity Colliders' was checked. The interaction was done using Unity colliders, but when rendering object volumes for lights, empty objects, particles etc, the collider volume was ignored.

So as you can see, the 2 selection modes IndividualObjects and EntireHierarchy have been removed. The main reason behind this is that they were quite rigid and now you can achieve the same and even more complex selection effects using the IRTEditorEventListener interface. There is a new chapter inside the documentation (chapter 6.1.1) which talks a bit about some helper functions which you mind find useful when customizing the object selection mechanism. It also shows you 2 simple examples of selection customization.

Previously, when the EntireHierarchy was still around, if you selected this mode, then the system would draw a selection box for the entire hierarchy. This no longer happens automatically because this mode no longer exists. However, you can now control the way in which selection boxes are drawn inside the EditorObjectSelection Inspector GUI. There is now a property which is called Selection Box Render Mode. The default is PerObject which means a selection box is drawn for each selected object. The other one is FromParentToBottom. This one draws a selection box from each selected parent down to the bottom. So the box will enclose the parent and its children.

Enjoy!

 

I have to say I'm truly enjoying working with the system. Amazing work.

However, I do have a question/feature request (I'll probably add it on my end). I'd love to be able to define objects that do *not* get added into the GameObjectSphereTree. We've got several custom terrain systems with well over 127000 tris. So, first time you click on an object, it can take upwards of 3 minutes while it builds the appropriate sphere tree objects. Excluding them (via some manual hackery) brings it back down to something more sane.

FYI, here's what I'm doing:

Code (CSharp):

1.        private bool RegisterGameObject(GameObject gameObject)
2.         {
3.             if (!CanGameObjectBeRegisteredWithTree(gameObject)) return false;
4.  
5.             // DIVERGENT BEGIN ***
6.             if (gameObject.name.Contains("TerrainSegment")) return false;
7.             // *** DIVERGENT END
8.  

What I'm thinking about doing is exposing a simple hashset of GameObjects to ignore, so you'd have something akin to:

Code (CSharp):

1.        private bool RegisterGameObject(GameObject gameObject)
2.         {
3.             if (!CanGameObjectBeRegisteredWithTree(gameObject)) return false;
4.  
5.             // DIVERGENT BEGIN ***
6.             if (m_Cullset.Contains(gameObject)) return false;
7.             // *** DIVERGENT END
8.  

With the appropriate accessors for m_Cullset.

 

Hi Octave!

I have a quick question. Can this be used to allow a player to move things around? For example, could they use this in-game to re-position furniture in a house?

Thanks!

 

Octave will give you more details, but yes, that's the intention of this plugin.