[RELEASED] Magic Markers: Visibility for Your Invisible GameObjects

The answer to your question is a combination of things, but mostly good news for you.

In general, Magic Markers are supposed to show the position of things, not the size of things. For example, I use Archimatix and ProBuilder a lot. It is useful to have a Magic Marker show the base GameObject to which those procedural meshes are attached, but if the Magic Marker itself was as large as the object it represents, it would be in the way and prevent you from clicking on the object you really want to edit. Oops! So Magic Markers deliberately ignore the scaling of the GameObject to which they are attached.

That being said, to be honest I never thought anyone would *want* to scale up the alert or question markers, so I didn't enable that slider on those. The Booth marker, also, is fixed size, because it is a standardized size to represent a humanoid character (other game engines use that same marker shape, at a size of 1x2x1 meters XYZ, to represent spawn points).

But I see your point, and I'll take that as a feature request. I'll make sure in the new version that all markers can have the scale slider, and I'll leave it up to you whether or not you use it. You are correct that I should have left this flexible for all the marker types.

Now, I do have some REALLY good news for you: In the new version, I already allow the marker *type* to be scaled in all three axes independently, to any size you would like it be, and separately for the primary and secondary meshes. So in the new version that is coming out soon, you could make an alert marker a full kilometer tall if you really want to. This feature is all done in my development version, and I'm just "final testing" it to be sure it's reliable. As I mentioned before, I also fixed the problem with the Edge Lines highlight mode.

I finished a major part of the new version last night. There is one more new feature I want to add in this release (it's a surprise...I'll post it in a few days once I'm 100% sure I can actually *do* it!), and then I'll be submitting the release to the Asset Store.

 

P.S.:

1. You don't have to apologize for questions! They're reasonable questions, and I had every expectation when I released an asset for sale that people would ask questions, report bugs, and offer suggestions. I'd be upset if people posted reviews asking for tech support, because that's the wrong venue for support requests. But you are using the support forum thread, which is perfectly appropriate.
2. I'm really glad to hear that you're finding Magic Markers useful and are using it heavily! The reason I made this asset was that I needed it for my own projects, and I decided since I needed it myself, others might also find it useful. It warms my heart to know my asset is helping others.

 

I'm not using the Alert mesh like you intended though lol. Using it to show a ship transports military to that location lol.
I probably should stop and figure out how to add my own mesh so i can name it to that.
My gizmo draw path works great with your route diamond meshes as you can see.
After im done with this test player. I may look it all over again and come up with some better ideas and maybe even create my own mesh names types.

One thought maybe give us a API to draw these lines between route points.
My animation frame comes with that option but i could see users not having an asset that has this.
I think i am gonna get rid of this animation frame im using so I may lose it.

Code (csharp):

1. MagicMarker.DrawPath(Transform[] Route,Color);

idk maybe MagicMarker already has something for this.

 

I implemented this tonight in my development version. All markers now have the scale slider. Where it makes sense, I allow scaling primary and secondary independently, but for some markers (notably the alert and question), the scales are locked into one slider because it doesn't make sense otherwise.

That other new feature I hinted is coming along nicely, too, and I think I'll finish it this weekend. This release has added more functionality than I had originally expected.

 

I've thought about that kind of thing, but I'm not sure if it belongs inside Magic Markers or not. There are a lot of questions, such as:

• Should the paths be lines, or splines? If splines, there are several mathematical algorithms, and all kinds of methods for positioning the control points.
• How would this relate to existing spline packages, such as Curvy, which really do splines at a high level? (By the way, I bought Curvy myself, and I highly recommend it if you need a full-featured spline manager.)
• Would it be better to provide integration tools to make Magic Markers work with one or more existing spline tools, instead of reinventing that wheel?

I'm not opposed to your idea, but it's not something I want to just "throw together" on a whim. If I do this, I'll need to think it out carefully and probably get some feedback from customers about how it should work.

 

I'm interested in lines/splines, too, with a vote for integration with an existing spline tool. This isn't a high priority thing for me, though. It would just be a nice, minor convenience.

 

Thanks for the feedback, from both of you. FWIW, I use Curvy a lot and was already considering integration with that to "scratch my own itch", so to speak. @TonyLi, what spline package do you currently use?

 

None currently, but I've used several in the past. I recommend choosing the one you want to use, and stick with it. It's a headache to maintain extra, semi-redundant integrations for multiple assets that do essentially the same thing.

 

I agree. Curvy is more complicated (but hugely flexible!) compared to some other spline tools. When I was shopping, I decided to take the time to learn one real powerhouse rather than something simple that I'd have to replace on a more complex project later. That decision has served me well.

Since Magic Markers comes with full source code, if I implement this for a complex case like Curvy, it should be comparatively simple for Magic Markers buyers to locally adapt to simpler cases if they need to do so.

 

I have some happy news! That experimental feature that I was working on is completed as of a short while ago. Now that I know it actually works, I can reveal it here.

Magic Markers will (in the upcoming version) offer direct support for automatically marking Colliders attached to GameObjects. There is a new component called MagicMarkerCollider. Just add that to any GameObject that has at least one BoxCollider, CapsuleCollider, or SphereCollider component, and the Magic Markers component will auto-detect everything it needs to know to make those colliders visible and directly selectable in the scene view, just like any other Magic Marker.

The new feature supports an arbitrary number and combination of Box, Capsule, and Sphere colliders on the same GameObject, and you can individually configure all the visuals just as you would on regular Magic Markers. Prefabs are fully supported, so you can make standard trigger zones, invisible boundaries, and so forth.

Once the MagicMarkerCollider component is added, you can use Unity's standard methods (either the inspector fields, or the "edit collider" function with the in-scene dot handles) to adjust the size and position of each collider, and Magic Markers will automatically adjust to follow.

Here are some teaser screen shots of the new feature. This is a deliberately-complex object with two BoxColliders plus one each of CapsuleCollider and SphereCollider.

In the inspector, you can also see the new settings that control how the secondary and highlight colors are determined. These enhanced controls are also on regular Magic Markers in the new version.



There are a few limitations to the collider feature, but hopefully nothing odious:

• As with regular Magic Markers, there are zero GC allocations in any of the per-frame functions, but if you adjust the size of the underlying collider component, you will incur a one-time GC allocation as the Magic Marker updates itself.
• The new component auto-detects all of the supported colliders on its own GameObject, but it turns out Unity's GetComponents() function does a surprising amount of GC allocation. So rather than calling it every frame, what I've done is to provide an inspector button to refresh the detection if you add or remove a collider. The button invokes a public method, so your own scripts can also call it if you want more frequent detection at the cost of GC.
• Because of the procedurally-driven rendering, a collider marker on the same GameObject as a regular Magic Marker is allowed but not a good idea cosmetically.
• MeshCollider is not directly supported in the new feature. You can, however, achieve basically the same thing by using the generic Magic Marker with the Mesh asset that is also used for your MeshCollider.

I still have to document the new feature, but it's working well in my testing and is almost certain to be in the upcoming release. This will be a free upgrade for all existing customers.

 

I've run into a snag in testing. The Android test build is causing a segfault, for reasons I suspect are related to thread contention. I can't replicate the problem on other platforms. I'm working with Unity to investigate and resolve, but this may delay the new release of Magic Markers by a few days.

I'm sorry for the delay, but I'm very committed to high-quality code on which you can rely for your projects.

 

I've found a solution to this problem. I'm still working with the Unity folks to see if the underlying cause is my code or theirs, but my workaround reliably prevents the crash, so I should be able to move ahead with release in a few days once I finish the documentation updates.

 

Further info: It appears that in the Android build, that preview camera is showing up with CameraType.Game instead of CameraType.Preview. I was looking at my code, and found that I already have a test in there to exclude anything that isn't CameraType.Game, but that one is slipping through. On desktop, it doesn't.

 

Good evening!

The 20180224 version of Magic Markers has just been submitted to the Asset Store for approval. This version took longer to release than I had hoped, but I think you'll agree it was worth the wait. There are a lot of new features, improvements to existing features, and (of course) bug fixes. The User Manual and Quick Start Guide are also expanded and reorganized.

The big changes in this version are:

• Collider Markers are attached to any GameObject that has one or more Colliders, to make those visible in the editor and optionally at runtime (for debugging). There is a wizard to quickly create a trigger zone, in Box, Capsule, or Sphere shape, with the Collider and Magic Marker already attached.
• New color options give you more control over how the secondary colors are computed. You can still manually specify the color and opacity you want, but instead of just one way to auto-compute the color, there are now three methods available in the inspector.
• Three-axis sizing of the primary and secondary parts, independently where this makes sense or automatically linked for markers like the Question and Alert where separate scales do not work well.

This version also fixes several bugs reported by customers. Thank you for the feedback and bug reports! Of the three main features listed above, two were the direct result of suggestions from users.

With all of the new features, Magic Markers still uses no GC memory allocations per-frame, except for a single frame if a script changes the geometry settings of markers.

This version has been tested (and submitted to the Asset Store) in packages for Unity 5.4.6, 5.5.5, 5.6.3, 2017.1.2, 2017.2.1, and 2017.3.0. Although Magic Markers does not officially support Unity beta versions, I have informally tested with beta 2018.1 using the built-in render pipeline (the default, not SRP) and found no problems.

Here is the complete change log:

### New Features ###

• Added Collider markers support
• New demo feature with "faction respawn" teleport zone
• Added capability to resize primary and secondary meshes in three dimensions
• More control over how secondary colors are determined for all markers
• Presence of secondary mesh is now switchable on all markers where it exists

### Improvements ###

• MagicMarker and MagicMarkerCollider inserted in Add Component menu tree
• Wizards to quickly create trigger zones with collider markers attached
• Set nonzero minimum for wireframe width to avoid confusion from invisible wireframe
• Show merged Size and Offset fields for marker types with linked prim/sec sizes, and make X part of that group
• Baked in -Z offset for Camera marker to keep it from ever showing itself on its own camera
• Reorganized some of the GameObjects in the demo scenes
• Reversed rendering order of primary/secondary meshes to improve cosmetics
• Cosmetic touchup of demo terrain
• Move demo scripts to MagicMarkers.Demo namespace. Update copyright and email in comments.
• Revised standard marker types to be more directly useful in real projects
• New scaling features in markers and custom inspectors, and updated marker type assets with new fields
• Two-finger touch emulates right mouse button so zoom supported on mobile demo.
• Performance tweak wizard, and match case of method names to current Unity practice
• Added explicit ordering to menus so users can put their local ones at the top

### Bug Fixes ###

• New version of gong04.fbx fixes scaling issues for import
• Workaround for Android build bug with preview camera set to wrong CameraType value.
• Fix null ref errors if a collider is removed, and push faster redraw after DetectColliders().
• Removed some debug scaffolding
• Removed extraneous SetPass() call from shader
• Improved position/rotation/scale behaviors of markers in complex transform situations
• Remove some unused variables and update comments in example scripts
• Enhanced init code to prevent null ref error if wizard re-serialized while window displayed
• Fix bug where disabled component would still render. Virtualized methods for easier extensibility.
• Minimum shader model set to SM 2.5 instead of SM 2.0 for legacy sub-shader

The new version will be a free upgrade for anyone who has already purchased Magic Markers. I will be providing additional video tutorials (modulo my available time to create them) for the new features.

 

The Asset Store team turned my approval around really quickly! I hope everyone enjoys the new version, and as always please use this forum or the support email if you find any problems.

Asset Store page: http://u3d.as/10YM

 

Any idea how to return a random location inside a cube just on x and z axis.
I was looking at this in the forum but it seems I need the mesh filter to figure this out.
Seems I would need to tap into Magic marker to use it as a marker of the area I mark.

Code (csharp):

1.  
2. public Vector3 GetARandomPos(){
3.  
4.    Mesh planeMesh = gameObject.GetComponent<MeshFilter>().mesh;
5.    Bounds bounds = planeMesh.bounds;
6.  
7.    float minX = gameObject.transform.position.x - gameObject.transform.localScale.x * bounds.size.x * 0.5f;
8.    float minZ = gameObject.transform.position.z - gameObject.transform.localScale.z * bounds.size.z * 0.5f;
9.  
10.    Vector3 newVec = new Vector3(Random.Range (minX, -minX),
11.                                 gameObject.transform.position.y,
12.                                 Random.Range (minZ, -minZ));
13.    return newVec;
14. }
15.  

 

There's nothing special about a cubic volume that would require a Mesh to define it. A cubic volume is simply a space that is bounded by x, y, and z each within specified ranges. You can store that in a Bounds if you want, or define two opposing corners as a par of Vector3.

Other than this, I'm not sure I understand the question.

 

The way im doing it now is I use two transforms and I figure out a random space in between it.
What I want to do is use a single transform with magic marker and cover an area showing something randomly spawns in this area.

I would need a mesh bonds to do this wouldn't I?
For my understanding the only way to get the space inside is using the mesh.

Or a better question maybe. How do you get a random spot inside your cube magic marker. In World Space.

 

A cube is just an abstract geometric construction; it doesn't have to exist as a visible object. If I give you two vectors, (1,2,5) and (3,4,7), then I have defined an imaginary cube of 2 units in each dimension, with the following eight vertices:

(1,2,5)
(3,2,5)
(1,4,5)
(3,4,5)
(1,2,7)
(3,2,7)
(1,4,7)
(3,4,7)

To get a random point inside that, all you have to do is

float x = Random.Range(1.0f, 3.0f);
float y = Random.Range(2.0f, 4.0f);
float z = Random.Range(5.0f, 7.0f);
Vector3 randomPoint = new Vector3(x, y, z);

You can make a Cube magic marker for this by putting the Magic Markers component with a Cube marker type on a GameObject at (2.0, 2.0, 6.0) with a Local Scale of 2.0. The Cube marker has its bottom center at the location of its attached GameObject (although you can override this with the Local Offset property). All of this can be done dynamically in a script if you prefer, but you didn't indicate that you needed to do that.

Don't think of "making a random point inside a Magic Marker". Think of your cube as a geometric abstraction, and pick your random point inside that. If you want a Magic Marker to match the size of your imaginary cube, that's a separate item from the random point.

 

Ya thats how I do random location right now using four corner vector3's. I know only two is needed. I'll probably switch to two now though since i'll have the parent square as the marker. My issue wasn't the math of doing the random location it was getting the two vector3s of the cube.
But ya thats a good idea. Just use a parent gameobject as the big square covering the area.
Thanks man that should work.

Idk if this exists in magic marker or not. Is there a mesh that overlays the ground?
My picture below shows blue route lines that stick to the ground cause of awesome Magic Marker.
Be nice if there was a plane mesh that took on the shape of the ground. So like highlighting an area of the map?
This is obviously for my spawning stuff in a random area.

I just wanted to say I couldn't of made my game with out your asset. Idk why I thought i was gonna be able to make my game with out viable spawn markers. That ground sticking thing is amazing for ground patrol routes. I can set up patrols so fast and move them around and adjust them. Its just simply amazing.

 

Not currently. Most people don't do it that way; they use a Projector component (see the Unity docs for details), or they use one of the decal or unit marker kits from the Asset Store. I considered putting something like that in Magic Markers, but some other assets already do such a good job that I didn't see a need to reinvent that wheel.

Hey, thanks for the kind words! Perhaps you could consider posting a review?

 

Idk I think it should be part of magic marker. Magic marker Should beable to mark anything your heart desires. Also why I think it should beable connect the routes with a line as shown in my pic.
The more assets you use the more you have keep track of in updating them.

Ya I'm gonna give ya a good review man.

 

I finally upgraded to your latest release. few issues.
Editor locks up for like 5 minutes after updating. I removed Magic markers completely before importing it back in.

If you go to Add Component Searching for Magic Marker won't show up in the list anymore. So you can't add the component.
I just realized your add Magic Marker wizard when right clicking on a GameObject thats super amazing. I"ll be using that instead anyways but still thought i should mention that Add Component doesn't work for some reason.

Code (csharp):

1.  
2. DrawMesh requires material.SetPass before!
3. UnityEngine.Graphics:DrawMeshNow(Mesh, Vector3, Quaternion)
4. MagicMarkers.MagicMarkerAbstract:DrawMarkerPass(Int32) (at Assets/Plugins/MagicMarkers/Scripts/MagicMarkerAbstract.cs:556)
5. MagicMarkers.MagicMarkerAbstract:DrawMarker() (at Assets/Plugins/MagicMarkers/Scripts/MagicMarkerAbstract.cs:532)
6. MagicMarkers.MagicMarkerAbstract:OnDrawGizmos() (at Assets/Plugins/MagicMarkers/Scripts/MagicMarkerAbstract.cs:341)
7. MagicMarkers.MagicMarker:OnDrawGizmos() (at Assets/Plugins/MagicMarkers/Scripts/MagicMarker.cs:163)
8. UnityEngine.GUIUtility:ProcessEvent(Int32, IntPtr)
9.  

I wanna start using the X mesh more for ships that can possibly land there so i don't put anything in its place.
You only allow to resize it to scale 10. This is the largest i can make it in this picture.
Think you should make the scale max to 30.





Grounded option appears to be broke in this newest version. It seems like it grounds it to the back side of the terrain. The bottom of the terrain mesh instead of the top.

 

Thanks for the bug report. I'll see if I can reproduce this ASAP. It may take a couple of days to fully investigate.

The grounding option didn't change in this version, so you may want to check the Y offset values on your markers. Again, I'll investigate to see if I can replicate that.

 

that error only happen when importing the asset. I tried twice. First importing it with out removing the package and then 2nd time removing the package first and then importing it.

 

Thanks for the extra info.

Had you moved Magic Markers to a different part of your project directories? If you did, then that would explain the import problems.

What version of Unity are you running?

 

Errrrrr..... That is what one might call....ummm...errrr... a specimen of insect life from the order Hemiptera. To wit, a bug.

It's not the scale that is the problem. The Magic Marker Type now has a "Size" field that lets you scale the marker type in fully arbitrary levels, anything that will fit into a Vector3. Unfortunately, there is a bug in the X Marker C# script that causes it to ignore what you put into Size. Fortunately, it's a one-line code fix.

Please open the file Plugins/Magic Markers/Scripts/MagicMarkerX.cs and edit line 23 so it looks like this:

Code (csharp):

1. primaryMesh = MakeMarkerMesh(xMarkerVertices, xMarkerTriangles, xMarkerUV, Vector3.zero, primarySize, Vector3.zero, true);

EDIT 2018-03-10: Changed the above snippet to make it more efficient. Please use this version instead of what I originally posted.

The change is replacing an occurrence of "Vector3.one" with "new Vector3(primary size.....)" in the fifth parameter to the MakeMarkerMesh() method call.

I most humbly apologize for the bug! I suspect it affects other marker types as well, and I will check them all when I submit the patch to the Asset Store in the next few days.

Note that the new SIze parameter affects the marker type and not the marker instance. This parameter is also applied ahead of the Scale parameter with which you are familiar, and the two are multiplicative. To use this:

1. In your Project view (not your Scene!), use the right mouse button "Create...Magic Marker....X Marker" menu to make a new basic X Marker type asset. Rename the new asset to something of your choice reflecting its purpose (such as "ShipLandingZoneMarker").
2. Now, in your Scene, use the right mouse button context menu to create a new marker instance of the ShipLandingZoneMarker type. Set its appearance as you like. Make a prefab if you want. Enjoy!

I'm attaching a screen shot of the X marker with the code correction I just posted above. You can see the marker is now much larger than the entire terrain of the Magic Markers demo scene. If that's not large enough for you, you can make it even bigger, as there are no hardwired limits on the Size vector in the marker type.

One thing you will enjoy here is that the markers do not use textures, so making them huge does not cause mushy UV projections. They do have UV coordinates internally, but no textures mapped to the UV.



EDIT: The sizing issue discussed in this post is corrected in the 20180310 release.

 

{sigh} It does. The ones you would most likely want to scale are okay, but some like the Alert marker also ignore that parameter. A word of caution: Don't arbitrarily apply this same patch to the other marker types; some of their sizing is more complicated than the X marker. I should have a new version up by early next week. Again, my apologies!

 

Quick update: I've updated the code patch I posted above, because I realized it wasn't as efficient as it should have been. Sorry about that; the first version was done at the end of a long workday.

 

Ah, that's not a "bug" so much as an "unintended side-effect" of a design change. Since I added Collider markers, I renamed the menu for the standard markers from "Magic Marker" to "Regular Marker". I hadn't noticed the unintended effect of making them harder to find that way. They're under a "Magic Marker" submenu now, and I didn't realize the hot-search feature didn't find that.

The new version that I'm working on today will change the menu names so "magic marker" will find both types.

Thanks for letting me know about this! I want the markers to be convenient to find and use in the menus.

EDIT: This issue is corrected in the 20180310 release.

 

I tried the upgrade in the largest project I've ever built, and it took about 90 seconds. The issue, I think, is that plugins compile ahead of non-plugin code, and I think the Magic Markers update may thereby have forced your other code to recompile.

I'm going to look at using Unity's new assembly definition to improve this for the newer versions. Magic Markers support Unity all the way back to 5.4.x, and there's not much I can do in those older versions (this is, of course, why the Unity folks added the new assembly feature).

 

Even after careful testing, I can't reproduce this one so far. Here are a couple of possible things that might be wrong in your project:

1. Depending on the color and opacity of your markers vs. the terrain texture behind them, I have observed a few cases where the Magic Markers can appear to be under the terrain due to an optical illusion.
2. If your markers are using your own custom mesh (i.e., the "Generic" type in Magic Markers), you will observe something like this (again as an optical illusion) if the polygon normals are reversed in your custom mesh.
3. The grounding component always places the origin of the GameObject to which the marker is attached at the level of the terrain. All of the Magic Markers have their origins either at the bottom of the marker (in most cases) or in the center of the marker (for a few special cases like the Camera marker that would normally not be grounded). If you offset the marker (using the Local Offset property) in the -Y direction relative to its GameObject, you can put it above or below the terrain. This was designed as a feature to allow quest markers to float in the air above the place where the player is supposed to go.
4. Is it possible you have your own grounding logic (such as a character controller, or a gravity-enabled Rigidbody) attached to the same GameObject or its parent? This would fight with the grounder for Magic Markers, and the results could be pretty weird.

If you can send me a screen shot of the marker where you are seeing this, with the marker selected in the scene so I can see its movement gizmo, and also the expanded inspector for the marker and the marker type, I may be able to help further.

One last suggestion: In the new version, some of the standard marker type asset files did change. One thing you can do to make sure your scene is on the latest, is to go to the Project view and "touch" the marker type where you're having the problem. Select the marker type asset, change one of its parameters, and then change it back. This will force Unity to rewrite the marker type asset file, and it will force Magic Markers to re-render the mesh.

 

I have a new version in testing and expect to push it to the Asset Store for review by Monday.

 

I have just submitted version 20180310 to the Unity Asset Store for review and approval. Here is the Changelog for this release:

Version 20180310

• Conditional use of UnityEngine.AI namespace avoids automated API update during import
• Bug fix where primary and secondary sizes were ignored on some marker types.
• Always includes "Magic Marker" string in create menu items, for easy hot-search.
• Force cached scaled meshes to null if marker type is detached or deleted.

This is just a bug fix release, with no major features, so the User Manual and Quick Start Guide did not change. I'd like to thank those who reported issues so I can continue to improve the asset.

I will post again when the new version is approved by the Asset Store team.

 

Magic Markers version 20180310 was accepted and published by the Asset Store today. This bug fix release is a free upgrade for all existing customers, and I recommend you do so at your earliest convenience. There were no changes to the serialized asset files from the previous version.

 

I've been testing Magic Markers in the 2018.1.0f2 version of Unity, now that it's out of beta. So far no issues, although as I've previously mentioned the Scriptable Render Pipeline feature is not yet supported. Magic Markers version 20180310 is now officially supported with the default shader mode on Unity version 2018.1.0f2.

 

interesting it be super nice if you could use some of the new futures to speed up performance.
I haven't built my first large map yet so not sure how everything will run with a ton of Magic objects in it.
Any chance you ever did a test and if so how many objects.. On a big map i think i'll have like 1000 or more.


But idk maybe Unity does some sort of culling when things are not seen in the scene view camera?

 

I intend to explore the new features when I have time, and I think Magic Markers will benefit from them, but it will be a fairly intrusive change to the code. I may have no choice but to release a separate version, because the change won't be even remotely backward-compatible.

I've tested Magic Markers with over 200 markers shown in a scene, internally. The release trailer demonstrates 100 markers, many of which are on moving navmeshed AI objects, running at about 100 FPS in the editor. I'd expect it to be a bit faster in a dedicated build, but to be honest it's not something I've tested.

Please remember that Magic Markers are intended primarily as an editor tool, or at runtime for testing and debugging. I'm glad to see them used as quest targets or other in-game purposes, but they are procedurally drawn meshes, which means they are inherently and unavoidably slower than static meshes.

Unity does have occlusion culling, but it does not affect Magic Markers because of them being procedurally drawn. Checking whether each marker is within the camera's frustum -- for each camera in the scene -- would quite possibly be slower than just drawing them all.

That being said, Magic Markers do not draw if they are disabled or inactive (which can be at the component level and does not have to involve the rest of their GameObject). So if you have, for example, a system that streams multiple Unity terrains, you could trivially check the X and Z coordinates of Magic Markers in the area as you disable or enable terrains, and disable those that are located within disabled terrains.

An even easier way would be to ensure, either during design or with a dynamic script, that all Magic Markers are children of some other objects that are enabled and disabled with the terrain object. If you're using them on units as unit markers, for example, the logic that moves that unit could check what terrain object's boundaries it lies within after each move, and then set the active state of the Magic Marker's MonoBehaviour (that is, the component and not the GameObject) to the same as the state of that terrain. The Magic Marker would not necessarily need to be a child of the terrain.

If the above isn't clear, let me know and I'll sketch out an example for you.

By the way, I think I know a way I could implement part of this logic for you within Magic Markers. You'd still have to do part of it in your app, because the marker doesn't "know" about the rest of your scene. No promises, but I'll take a look at feasibility as my time permits.

 

In case anyone's curious, today I began looking at Magic Markers in the Scriptable Render Pipeline modes of Unity 2018.1. To my surprise, the markers actually appear to work just fine in the Scene View, but -- exactly as expected -- they cannot render in the Game View or in a runtime build with SRP.

As a reminder, as long as you are not using the new SRP preview feature, Magic Markers work just fine in Unity 2018.1. It's only the SRP where there is an issue, and every asset with a custom shader will have to be modified to support SRP.

I'm not treating SRP support as an urgent priority right now, since not many people use SRP yet, but I am working on it. If anyone who has bought Magic Markers really needs this soon, please let me know and I'll bump the priority higher.

UPDATE 2018-07-12: The High Definition Render Pipeline is still very much a work-in-progress for the Unity team, and it really doesn't have some of the API features yet that are needed for a clean integration of Magic Markers. My testing so far has revealed that Magic Markers still work in the Unity Scene View even with HDRP for the project, however. The forum thread for HDRP has Unity saying it will still be a preview-level feature through at least 2018.3, and that its APIs are in flux. That being the case, my plan is to continue to watch HDRP development closely but not to actively work on supporting it in Magic Markers as a high priority, unless a customer requests this. If this is something you really need quickly, please do let me know here on the forum. I am committed to making this work eventually, but I think Unity itself isn't ready yet, a position which their own engineers' posts on the forums support. I am going to look at the Lightweight Render Pipeline (LWRP) soon to see where it stands, and I'll post here after I've had time to investigate.

UPDATE 2018-07-23: After some discussions with the Unity team and some early adopters of the LWRP, I've also concluded that it is still too early to integrate LWRP into Magic Markers as a procedural render step. One of the Unity developers says some of the APIs I need are recently added to the bleeding-edge version, but they are not yet documented, and he has advised me to wait since example code and documentation are planned soon.

I'm investigating two different ways of accomplishing the goal here, and the idea I think may actually be best will need some R&D on my part to see how it works in practice. I'm 100% sure it will work, but I need to prototype it to make sure the workflow remains clean.

I'll have more to post on this in a few weeks. In the meantime, thank you for supporting Magic Markers. I remain 100% committed to maintaining and improving this asset, but I want to take the time to do it "the right way", and so far no one has been asking me to rush this. The offer still stands -- if your team needs SRP support, let me know and I'll take that into account in prioritizing my workload.

 

I finally upgraded to your latest version. Are your sells doing good with this asset? Hope it is. I want it to keep getting better. Course it already does everything I need it to. I mean more so like keep getting updated so it doesn't get deprecated code etc..

What will that new Render Pipeline do? Better performance?

Anyways I found a bug just now right off the back. I notice if your magic marker starts below the terrain it won't snap to ground using the ground button. Once i move it above the terrain then it worked just fine.
Using latest 2017 LTS version.

 

I am absolutely committed to maintaining Magic Markers, out of enlightened self-interest if nothing else. I originally created Magic Markers because I needed it, and only afterward realized others might benefit. I haven't needed to do an update for Unity compatibility lately, but rest assured I'm testing with each new Unity version as they are released.

The Lightweight Render Pipeline provides better performance on low-end systems such as mobile devices, whereas the High Definition Render Pipeline is designed to "pull out all the stops" for ultra-quality graphics on high-end systems with fast CPU and GPU. The whole Scriptable Render Pipeline (SRP) system is designed to give developers full control over the rendering pipeline; LWRP and HDRP are just two "reference implementations" of the more generic SRP.

That last sentence actually expresses why I'm not yet able to implement Magic Markers in SRP -- the two reference implementations are not yet fully stabilized and documented by the Unity team. I am following development closely, but waiting to work in earnest on this, based on advice from the Unity team who assure me better documentation is coming in the next few months. The Unity engineers indicated that if I try to move ahead too quickly right now, it could result in wasted effort and a need for Magic Markers users to update again later. That's not good for me nor for my customers.

That may not be a bug, but rather a feature. There is a finite distance above and below ground at which the markers will snap. When I was developing the asset, I found that I could make the "snap downward" distance quite large, and all is well, but if I made the "snap upward" distance too much, it made it impossible to place a marker on a ground surface underneath another collider. If you look at the Magic Markers demo scene, you'll notice there is a bridge across the river at one point. If I make the snap distance too large, you can't auto-snap a marker to the ground under an object like that bridge.

I will retest, though, and make sure this feature is working as it is intended to work. If you wish, you can adjust the snap distances by changing line 36 of Assets/Plugins/MagicMarkers/Scripts/Grounder.cs; just remember that you will need to re-apply your change after a Magic Markers version update.

 

Hello, @Shadowing. I had promised to test this for you, and I wanted to report back.

I loaded Magic Markers in Unity 2017.4.10f1 and tested against a standard Unity terrain object in the Magic Markers demo scene. Here's what I did:

1. Take a marker that had been resting on the terrain and was marked "Ground in editor" in its inspector. I temporarily turned off that option.
2. I used the Unity gizmos to move this object below the terrain by about 8 meters.
3. I pressed the "Ground" button in the Magic Marker inspector for the object. It snapped to the terrain.
4. I repeated the test, but instead of using the immediate Ground button, I instead enabled the "Ground in editor" option. Again, the marker snapped to the terrain.

In looking at my code, I did notice a couple of subtleties that I had not mentioned before, so let me pass those along for information:

Hysteresis

I had forgotten that there is an offset in the up/down raycasts to keep the object from "jittering" if the continuous grounding is enabled. This could have otherwise been a problem if there were two colliders one above the other, but very close together in the Y direction. The hysteresis is 2.0 meters by default, and it's applied in the opposite direction of each raycast. So the downward raycast starts 2.0 meters above the object's pivot, and the upward raycast starts 2.0 metes below the object's pivot.

This also helps to ensure that floating point round-off doesn't cause the object to miss a collider it was already sitting on on the next update. For example, if you had a collider whose top was at 2.15 meters Y, and the marker was sitting on it on one frame, then the floating point roundoff might make Unity report its height as 2.1499999 meters Y the next frame. If I didn't have the hysteresis, that marker would think it needed to snap upward by 0.0000001 meters the next frame. This probably wouldn't be visible, but it eats performance, so I took precautions to make sure it doesn't happen.

The net effect of the hysteresis is that the up or down snap distance I stated in my earlier post (10.0 meters upward, 20.0 meters downward) is actually 2.0 meters less in each direction.

I have done some additional testing today, and found that this works perfectly well with less hysteresis. I've been testing successfully at 0.5 meters hysteresis. You're welcome to make the change in your own system to try this out. It's in the file Assets/Plugins/MagicMarkers/Scripts/Grounder.cs, line 24:

Code (csharp):

1. public static Vector3 hysteresisY = new Vector3(0.0f, 2.0f, 0.0f);

Change the 2.0f for the Y coordinate to a positive number of your choice (such as 0.5f), then start and stop Play mode, or reload your scene, to force the object to re-initialize.

There is a pretty good chance I'll use a lower value in the next Magic Markers version. I think I put in 2.0 during testing "to be very sure" but didn't remember to reduce it once I had tested things out. If other users of Magic Markers have an opinion on this, please feel free to weigh in.

Grounding Directions

The grounding algorithm gives a slight preference to snapping upward versus downward, if it finds colliders in both directions. This was because during testing, with markers sitting between a collider above and a collider below, I found that making it prefer up rather than down snapping made it "feel" slightly more intuitive in the editor.

If you're still having this problem, @Shadowing, let's talk about it in more detail, and please tell me how to replicate it. If I have a bug, I very much want to fix it!

Thanks again for buying Magic Markers, and I value your constructive feedback and suggestions.

 

...And all of the above caused me to take a look in general at how the auto-grounding works. I'm working on some improvements to auto-grounding, and I've also implemented a code simplification in part of the custom editor dialogs. So -- tentatively -- it seems there will be a Magic Markers update coming soon. No target date yet, because I have a lot of testing to do. What I will say is that this will be a free update to existing customers.

One other thing I should mention is that "Ground in Game" is an exception to the no runtime GC behavior of Magic Markers. This is because grounding needs some vector arithmetic that can't be done without allocating one Vector3. There is a warning in the Inspector about this, but I'm going to make it more explicitly clear in the next documentation release. This is a feature that is likely to be rarely used, so it's unlikely this will be a problem for most users.

 

Update: I held the maintenance release until after Unite, because I had two other back-to-back business trips right before Unite. Above all else, I did not want to rush out a release that hadn't been thoroughly tested. It's code-complete, so I'll be uploading as soon as I finish QA, although I'm a bit obsessive about that part so it may be a few days yet.

While at Unite, I was able to schedule some one-on-one mentoring from Andy Touch, part of the Unity team who's working on the Scriptable Render Pipelines. The features I need in order to make Magic Markers compatible with LWRP and HDRP are coming together at last, and Andy was kind enough to give me some design tips so I can get it right. I'm now quite confident I can make Magic Markers work in SRP, and I'll soon begin working toward that end. If any existing customer needs SRP, please contact me and I may be able to let you have an early release for testing. To be realistic, this is at least a few weeks away (though I'll compress the schedule if it's vitally important to an existing customer). As always, my philosophy is to do Magic Markers development well rather than doing it fast.

 

I am pleased to announce that Magic Markers version 20181111 has been approved and is now available on the Asset Store page. This is a maintenance release with bug fixes, some code efficiency improvements, and better auto-grounding based on feedback from customers (thank you!). One nice side-effect of this update is that a single code base now supports Unity 5.4.6 through 2018.2.15. Although I cannot officially support Unity betas, I can tell you informally that I have tested the new Magic Markers version with Unity 2018.3.0b9 and found no problem.

For all versions of Unity, Magic Markers still requires the Default Render Pipeline. I am working on support for LWRP and HDRP, but that is not yet in this version.

This version also includes minor documentation updates to improve clarity.

As promised, the upgrade is free for all existing customers. It should be safe to apply in-place, but as with any asset upgrade you should back up your Unity project first.

Obtain the new 20181111 version here: http://u3d.as/10YM

 

Sorry i been late on responses just super busy with a dead line on my project.

I wanted to show you this though. I have a issue with seeing magic markers in thick grass.
Notice the circle marker in this picture.
be cool to have a vegetation studio support with magic marker where it masks everything and only works during edit mode.

 

I have a pretty large problem. Idk if it just started with the last version I just updated too or what.
If i hit grounded in editor it sets the y axis to 128.
I then unclick grounded.
I adjust the transformer y axis to say 127.
Then during run time it pushes it back to 128.

Also am I right about this? local offset only effects the magic marker placeholder it never effects the transformer right?

 

Good morning, and sorry you're having problems. Let's gather some info to get this working for you.

Are you observing this behavior in the editor, or only at runtime?

If you are observing it only at runtime, what happens if you disable the runtime auto-grounding of the marker?

Do you have any C# scripts or other game functionality that also modifies the transform of this same GameObject, or of one of its ancestor objects in the hierarchy? If you have any other code that moves the object, then you should disable the runtime grounding of Magic Markers, because Magic Markers and your other code won't be able to coordinate with each other. If you are doing external movement, there is a very simple API call in Magic Markers that you can invoke from your own code to do the runtime grounding in a way that does not conflict with what else you have going on. The only requirement is that you call the grounding method at the appropriate time based on your other code, rather than letting Magic Markers do it every frame.

Is your scene small enough that you could make a ZIP file of it and post it on Dropbox (or equivalent) for me to look at?

The way the grounding works is that it emits a raycast upward and downward from the current transform position of your object. It looks both upward and downward, for a limited range (relative to its current position). If it finds a Collider in only one direction, within its limited distance, it snaps the transform to that collider. If it finds Colliders both above and below, it snaps to the nearest, but with a slight bias toward the one below, because normally in the editor you would position a marker above something else (like a terrain or room floor) and let it snap downward.

If all else fails, perhaps you could install the Zoom client on your workstation, and we could make an appointment for a screen share so I can see the problem firsthand and help you solve it.

Local offset only affects the magic marker's origin point, relative to the transform of the GameObject to which it is attached.

Automatic grounding, both in editor and at runtime (if the latter is enabled) modifies the transform position (but never the rotation) of the GameObject, but grounding does not modify the local offset of the marker.

 

Good morning! Thanks for sharing the picture -- it's always great to see Magic Markers in use in a customer's project!

Could you perhaps edit your post in place, and replace the picture with a higher resolution one? I can't see the issue clearly with the small size screen shot.

Also, I am not sure I understand your feature request. Could you elaborate a bit on what it is that you are requesting, since I don't use Vegetation Studio myself?

 

wow vegetation studio is amazing. I wouldn't dare make any game that needs grass, trees or rocks with out it. Here is the link if you haven't heard of it. Its Vegetation in real time using masks. Unity did a huge blog post about this asset a while back.
Its so good. Watch the video it will blow your mind. A lot of big assets on the store are providing support for it. Easy Roads, R.A.M - River Auto Material etc...
https://assetstore.unity.com/packages/tools/terrain/vegetation-studio-103389

The issue happens during run time in the editor. Idk about on a build.
Heres my component settings.
I can adjust the y axis on the transform just fine the magic marker moves where it should.
But when i go into run time it snaps to the terrain. which sets it to 128 on the y axis. This test map is a flat terrain surface.




As for the feature request here is a new photo. I don't understand all my pictures are screen captured on a 1k screen? See how the grass is covering the marker to a point its hard to see it.