[RELEASED] Magic Markers: Visibility for Your Invisible GameObjects

I'm aware of it, just haven't used it yet.

Thanks for the additional information. I'll try to replicate the problem here if I can.

 

@Shadowing, I have not been able to replicate your issue with grounding. If I have the marker settings the same as yours, I can go in and out of runtime freely without the marker snapping to the terrain.

I'll still be glad to assist you in troubleshooting this, but we will need to arrange a way for me to examine your project since I can't replicate it in my own environment.

 

@syscrusher tiny issue. I'm getting a compiler warning:
Plugins\MagicMarkers\Demo\Scripts\GameManager.cs(38,5,38,48): warning CS0618: 'Object.DestroyObject(Object)' is obsolete: 'use Object.Destroy instead.'

Would appreciate if it can be resolved in your next update

 

Are you using the latest version of Magic Markers? There were a couple of these warnings that were fixed by the most recent update.

Also, what version of Unity are you using, so I can replicate this problem?

Thanks for the problem report.

 

Any chance we can get Magic Markers to be moved from GameObject to go under Tools instead in the editor?
There is enough stuff under Windows anyways.

I'm currently going around to all the major used assets on the Asset store and asking if they will do the move as well.
This way we create a more of a Global Standard.

Several already use Tools
Odin
Opisive
Natural Manufacture

I understand you put it under GameObject cause its related a lot to game objects. But really lots of other assets are as well.

Also I'll be getting back with you here in a week or so about that bug I reported with grounded objects. Moving around like crazy on my project lol. Its a pretty big problem actually. I'll reply to your original reply at that time and provide more information too / videos.

 

@Mohamed-Anis I've been watching for a reply about your Unity version. I tested with the current Asset Store version of Magic Markers, and Unity 2018.3, and I am not getting this warning. I'll be glad to fix it if it's a MM bug, but I'll need the version info from you so I can replicate the problem. Thanks!

 

I've got Magic Markers under GameObject because that is where the Unity documentation indicates that components should go. Magic Markers adds a MonoBehaviour script -- a component -- to your GameObject. If the user community wants it under Tools, I'm willing to consider that for a future version, but there's a "good reason" why it's where it is right now.

FWIW, this all may change with the next major revision. (Note: This is in a VERY EARLY planning stage, so subject to change!) I am very seriously looking at using Entity Component System and Unity Job System in the next major release, because Magic Markers is exactly the kind of low-overhead runtime tool that would benefit greatly from ECS and UJS. That move would be a big architectural change for my code.

To allay any concerns about upgrades, I'm using Magic Markers extensively in my own Unity projects, so I deeply understand how much work can go into setting up custom marker types and prefabs. I'm extremely committed to providing automated upgrade scripts to smoothly migrate your projects. Before I release any major new version that breaks backward compatibility, I'll be communicating openly with existing customers to understand what's needed for migration automation and make sure I don't break your projects.

 

Sorry.. slipped my mind since it's just a tiny issue (a WARNING, nothing breaking and works perfectly). I'm on Unity 2018.3.0f2. And I'm on the latest (downloaded from Unity asset store, not a localy copy).

 

Thanks! I understand it's just a warning, but I want to try to replicate it and take care of it anyway.

 

I guess don't worry about it. Will reply again if i see it after an update on magic marker or unity tks!

 

Good news! I was able to replicate this warning last night, and I'll make sure to fix it in the next release. Thanks again for the report!

 

I have begun testing Magic Markers with Unity 2019.1.0f1 (still technically beta). As always, pre-release Unity versions are not officially supported for Magic Markers, but so far everything is working as intended in my own testing.

I'm still working on a version upgrade to support SRP and hope to have a progress report soon.

 

Hey Syscrusher i was thinking of a cool simple tool today. Maybe be something you may consider adding to this asset.
since its simple and it does have to do with Area and spawn.

Wish i could draw out a area on the map and then find a random spot inside that area

 

Thanks for the suggestion. I've given some thought to a feature of this type. No promises, but I'll keep it in mind as a possibility when I continue working on the next version.

 

Is it possible to add something where the mesh of the placeholders/markers get culled when the camera is far enough away from it? A global setting for us to choose from.
I'm concerned on the performance hit when I have a ton of quest items in area in the editor. I know the meshes are simple. From the tests I've run on culling it seems some sort of culling is better than no culling.

I have a 4k size map. I have no need to see markers further than 300 units away or so.
Other thoughts. I should probably be marking these markers as static shouldn't I?

 

Good morning, @Shadowing. That is a great suggestion. I tested with well over 100 active markers in the scene and still got fast render speeds, but improving performance even further is certainly worth doing.

I'll take a look in the next version at having full occlusion culling support for the game-mode renders, but as a simple step right now you can try adding the following code to MagicMarkerAbstract.cs, inserting this beginning at line 414 in the most recent Magic Markers version (immediately before the test for drawAllInGameMode):

Code (CSharp):

1.             // EXPERIMENTAL: Skip render if outside camera's clipping limits
2.             float distance = Vector3.Distance(transform.position, Camera.current.transform.position);
3.             if (distance < Camera.current.nearClipPlane || distance > Camera.current.farClipPlane) {
4.                 return false;
5.             }

I tested this myself and it seems to work without causing any problems. Make sure you insert this at the correct location, or you may break some of the other runtime-rendering logic. I added a Debug.Log() inside the conditional to verify that the correct markers in my test harness were being suppressed.

Be aware that this test is per-camera. It needs to be that way, because you might have a mini-map camera or a multiplayer "couch coop" game with several cameras in the scene, so markers may be within the culling frustum of some cameras but outside the frustum of others. (The code snippet posted above just checks the clipping planes, not the full frustum, because I wanted to get you an answer as quickly as possible and because checking the clipping planes is less computationally expensive than a frustum cull.)

Another approach you could take is to have your quest marker logic disable the Magic Marker components on the quest targets themselves when they are not close to your player object. Since Magic Markers doesn't know which object or objects in your scene represent players, it's not possible for me to build that support directly into Magic Markers. On the other hand, if you do that in your game logic, it will also cull those markers from all cameras including the mini-map or multiplayer situations. So it's probably a better solution but takes a bit more work on your part. As an aside, I verified that disabling the Magic Marker component on a GameObject does skip the render of that marker. You don't have to disable the GameObject itself, just the Magic Marker script component.

As a caveat, please do remember that (as discussed in the documentation), Magic Markers at runtime are intended for a relatively small number of markers at a time, say a few dozen. I'll try to help as I am able, and of course if I can improve performance in the next release I'll certainly do so, but I can't categorically promise to support huge numbers of runtime markers since the runtime-visible option is intended primarily as a debugging tool.

 

If by "further than 300 units away" you mean, "away from the player", then my suggestion for a player-centric enable/disable of the Magic Marker components will work very well for you.

Do you perhaps already have some game logic that tracks the 'area of interest" for the player, with respect to turning on and off particle effects, animations of environment objects, NPC movement, etc.? If so, then hooking into that logic might be the right way to go.

As an alternative, you could consider adding a separate Camera that is a child of the Main Camera at exactly the same position and rotation (that is, zero out its local Transform). Be sure to set the culling mask on this second camera to Nothing. Use the camera selection logic already in Magic Markers to have your quest markers rendering only on that child camera, not the Main Camera. Make the FOV and other parameters of the two Cameras identical, except the far clipping plane for the child camera should be set to 300 meters. Use the experimental clipping plane support that I posted previously.

Normally, adding an extra camera will cost performance, but here I think it might not be an issue. The render step in Magic Markers is called per-camera, so in this case your Main Camera will be trivially rejected by Magic Markers very early in the rendering logic. I tested this in my own environment as well, and although I can't cite performance metrics I do know that the markers do render as intended in this configuration, with the one caveat that they will double-render if you enable the debug mode to force *all* markers to render at runtime.

Bottom line: I recommend the "area of interest" logic that is more specific to your game, if you are able to implement it, but the two workarounds I've suggested should help if you can't add that logic or exploit logic you already have in the game. The example C# code for clipping plane support should be okay regardless, so I would encourage you to go ahead and try that even if you also do one of the other methods.

 

As you know, I've been working on getting Magic Markers to work in the new Scriptable Render Pipeline (SRP) modes. It has been challenging because the SRP implementations from the Unity team have been a moving target, and because the documentation lags the new code features in spite of their team's efforts to keep things in sync.

Tonight I have some good news to report on this effort: I have a working prototype and a functional implementation of the custom Magic Markers unlit shader that supports the wireframe feature. This is still a pre-alpha version with some known limitations (for example, the Fresnel effect is not working correctly), but getting the wireframe to function in SRP is a major milestone. So far I have only tested in HDRP, not LWRP, but all the APIs I am using are from the SRP Core and not a specific pipeline, so I am hopeful this code will work on both.

Here are some screen shots of the shader in the HDRP example scene. The cube is just a standard Unity primitive with the custom shader applied, but the capsule is actually procedurally-drawn geometry using a test harness excerpted from Magic Markers and updated to the new Unity APIs. The first picture is from the scene editor, while the second is from the runtime game mode window.

 

I'm finally building my first planet players will play on. Before it was just a demo test planet. This real planet will probably have a few hundred markers on it. Probably around 500 honestly.
Even if 500 doesn't lag though. Gotta add that with my vegetation rendered and buildings etc...
Right now im already pushing the limits of the editor. Thats cause I like to work with vegetation on etc.. lol
My culling for my game is only a runtime culling. I don't have a system that culls not during runtime for the editor.
Thats mostly cause I use LOD's for everything even if there are only one mesh on a model.

 

You should definitely add the sample code I posted and check the clipping plane distance on your cameras. With 500 markers, you might want to consider a little game-specific smart culling. If you are careful in how you do this, you could use your culling script on more than just Magic Markers and apply your same script to some of your other GameObjects such as the parent objects of complex buildings.

Thinking about this question has made me realize I can probably improve on that simple culling by also using vector math to figure out if the camera is facing away from the marker, regardless of the camera's FOV. I am trying to avoid a full frustum visibility calculation because most users won't have this many markers, and I don't want to speed it up for this unusual situation in a way that makes it slower for everyone else. But if a simple dot product can give me a better trivial rejection, that is a good compromise.

I'm actively working on the next version, as evidenced by the screen pics I posted a few days ago. The SRP support has been harder than I expected because they changed the API hooks that I was using for the render as well as the new shader requirements. Last fall at Unite, I got some one-on-one time with one of the SRP devs to discuss how to approach it, but then the APIs he recommended to me also changed shortly after that. The LWRP is now released, but HDRP is still technically a preview (but finally stabilizing), and my goal is to support SRP generically rather than just specific implementations of it.

In any case, the culling code (or more likely an improved version of it) is on my road map to include as part of the next version of Magic Markers.

 

Survey question for all customers: Are you using Magic Markers in any Unity version earlier than 2017.4? If so, what Unity version are you using, and do you plan to upgrade soon?

For the next release, I am seriously considering deprecating support for Unity 5.x so I can deinstall 5.4, 5.5, and 5.6 from my development workstation and simplify my release process. Data provided by the Asset Store team says only a small percentage of developers are still using Unity 5.x any more. Most are on 2018.x and 2019.x now, but a few are still on 2017.x. My thinking is that people on 2017.1 through 2017.3 will probably upgrade soon to the 2017.4 LTS at least, so I think I could safely support that as the earliest version. This is your chance to tell me if you disagree, or if in fact you think 2017.4 is too old and I should support only 2018.x onward. What do you think?

If you're running an older release, please let me know if you feel you still need Magic Markers to support that release for new projects, or if this is just code in "maintenance mode" for you, and you're doing all your current projects in a newer Unity. (In other words, perhaps you are technically "still using" an old Unity version but are okay with keeping your current Magic Markers version for that legacy work.)

If you are using Magic Markers in 5.x, and if I do officially deprecating support for those versions, I would still keep an archive of the current release and send it to you on request if you ever need it (given you provide an invoice number from the Asset Store as proof of purchase).

Thank you for your comments and suggestions. It is always a balancing act for asset publishers to support the Unity versions our customers need but not over-complicate our release processes.

 

Ya trying to depreciate older Unity is a good idea. Those Unity versions are awful anyways lol. Unity is only good from 2017 an up anyways. I just recently moved to 2019.

Anyways I'm having a pretty big issue with placing things exactly where i want them.
Say you are using a capsule Marker and I place it on the terrain.

If I spawn my enemy soldier using the position of the transform of the Magic Marker component
The enemy won't spawn in the center of the marker. Seems he spawns on the back left of the Capsule mesh point.
I know you have the offset option but that takes to much time adjusting that.
Any ideas how I can fix this? Its a pretty big problem cause a marker should be exactly center with what im placing.
Here are two examples.

Here I have a tower I'm spawning my guy inside of. This will actually spawn him way to the left where he is sticking out side of the tower a little.




Another example to is If placed my guy next to this building. This will actually spawn my guy on top of the building instead of on the ground cause the marker is to close to the building.

 

The Magic Markers have no control at all over where things spawn -- they are only a visual gizmo drawn for the designer.

If you're spawning characters onto a Navmesh, it's possible that your NavMeshAgent is moving them to a different location than you intended because of clearances to static colliders.

Have you considered that the physics engine may be moving your characters because your actual spawn points have their capsule colliders overlapping the colliders of environment objects?

Try disabling the Magic Marker component on your spawn point object, and you'll see that it has no influence. The only time Magic Markers will move their GameObject is if you have the automatic grounding enabled on the Magic Marker component. If you have automatic grounding enabled, make sure you turn off the option to auto-ground at runtime.

 

Oh ya i forgot about something i read a few months back when spawning something on the nav mesh there is a method I'm suppose to use instead of just setting the transform position. Thats probably whats going on.

 

I'm now using NavMeshAgent.Warp()
It didn't make any difference though. I guess i have some testing to do.

I'll make a separate script that spawns something to help narrow down whats going on.

 

Warp doesn't shortcut the process of NavMeshAgent seeking a navmesh position after you warp the object; it just notifies that code more explicitly that it needs to do so, rather than it having to guess from the changed transform.

Your plan to make a testing script is a good one. I'm confident the markers aren't the issue here unless you have runtime grounding enabled (which would be a bad idea anyway), because they do nothing whatsoever to the transform other than query it to get their own draw position. They're just visual gizmos, not action sources.

 

Ya you are probably right it has something to do with navmesh snapping to nearest link or something.
I understand what you are saying about warp now.
Can't figure out how to make it snap instantly after I set warp though.
I did SetDestination after warp but that didn't work.
Maybe SetDestination has to run for a few frames for it to warp.

 

Alright I ruled out it being caused from Magic Marker lol
Still no idea why this issue exits though. So far everything is pointing to nav mesh.
But why im not sure.

 

I noticed magic markers render before any of my other meshes.
anyway way to stop that?
as you see in this picture im working on this soldier but its annoying cause the marker is in the way while Im adjust messing with him.

 

Actually, the markers render after other things. They are in the transparent rendering queue. Take a look at the code for the shader, and you'll see this as a parameter; you can adjust it as you like to get things in the order you want.

I notice in your screen shot that the marker you have is opaque, with an alpha value of 1.0. If it's just the visual that bothers you, simply reduce the alpha of its primary and secondary colors, and turn off the checkbox that forces the secondary to be opaque. You can make the markers almost entirely transparent if you wish.

Also take a look at the render queue settings for the material shader on your character. There can be visual artifacts if you have an opaque object that is set to render in the transparent queue, if that object is in front of or behind a Magic Marker.

Can you make a sandbox project that has just your soldier, with the material and its shader, and make it available for me to download and try to replicate the problem?

 

In case anyone is interested, I had a brief opportunity today to experiment with the Linux native version of Unity Editor 2019.1.8f1 in Ubuntu 19.04, as a native boot on my system with Nvidia GPU. The Linux editor version is still experimental, so I can't officially support Magic Markers in that editor (but they are supported in Linux builds from the Windows or Mac editors). However, I'm pleased to report that Magic Markers worked correctly for me during my testing, with the Nvidia proprietary GPU drivers installed. I did not test with Nouveau drivers, as my time was limited. In this environment, the OpenGL version reported by Unity was 4.5, and the wireframe highlighting mode of the custom Magic Markers shader works correctly.

I stress-tested a standalone Linux x64 build by running the Magic Markers demo scene in full screen mode at 4K resolution and maxed-out quality settings, with 300 players spawned in the scene in debug mode. The frame rate wasn't spectacular but was not too bad. I wasn't set up to measure it precisely, but I would visually estimate around 45 to 50 FPS on my system with a GTX 1080 GPU. Remember that 300 visible Magic Markers in a scene is a stress test and not recommended for production builds.

 

I don't remember this issue existing in the past. Maybe its only a issue with Unity 2019
I do have like 12 shader keywords being ignored atm due to to many key words.
I'm just using the standard shader

 

The shader keywords limit may be the issue for you. I've never seen the markers behave that way, but I've not tested them in a scene with the shader keyword limit exceeded.

Can you try to replicate the issue in a small test project without that, and if it still occurs, make the project available for me to download?

 

I finally figured out that positioning issue. Was something with my spawn logic Makes sense now since i couldn't find anything online with anyone else having the same issue. I guess i was a bit over confident of my code lol.

 

I've been coding for over 30 years, and the most important lesson I have learned is to always suspect my own code first.

 

Oh man I found a big problem with Magic Markers.
Its lagging the editor super bad.

Here is a video with me spinning the camera around. Watch it lag with gizmos turned on and then watch the lag go away when gizmo's turned off. Just to make sure its Magic Marker doing this. Instead of disabling gizmos I minimized the Magic Marker component with the same result.

Now with Magic Marker disabled I enabled my military base as shown in this picture below. This is like 3 to 4 million tris showing in this picture. I spin the camera around real fast and no stutter lag. Smooth as butter.

That huge ship in the back ground by the way is just a picture. Using an imposter system.

I started wondering why my test scene was running so smooth compared to my map that people play on. Slowly started narrowing it down. I don't really have that many Magic markers on the map. Id say 200 total? Only 1/4 of my map is competed and I plan to add way more.

For now i'll collapse Magic Marker when I'm not needing to see it in the scene.
I can't imagine its the Magic Marker mesh causing this lag? Must be editor code running? Maybe the grounded option in editor?

 

Good morning! Sorry you're having a problem. Let me get some further information to narrow it down.

First, having Ground in Editor enabled is not a problem because that setting is inactive in play mode. However, please check to make sure you do not have grounding enabled for play mode. If you do, turn it off. That setting is only needed if the markers are sitting on top of objects that move, for example if you had procedural terrain that generated at runtime. Even procedural terrain does not need that setting, if it's procedural in the scene view and not actually during the game.

The grounding at runtime is there for those very rare situations, but it comes at a huge performance cost. So absolutely turn it off if you don't truly need it. Again, Ground in Editor is not a problem.

Second, you mention that you have about 200 Magic Markers enabled at runtime. That's actually quite a lot. As mentioned in the documentation, Magic Markers is intended primarily as an editor tool, but can be enabled at runtime for debugging or for limited usage such as quest targets or in-game points-of-interest. You're using it for marking large numbers of objects (battle units?). I'm happy to help you make this work, but please understand that it may take some iteration together because you're pushing my tool to do something I didn't originally intend. (Again, I'm glad to help you as long as you're willing be a partner in the process.)

Third, are you using custom meshes for any of your Magic Markers? This tool draws all the meshes procedurally, including custom meshes you have defined as added marker types. The reason Magic Markers behaves this way is so it is an almost 100% C# tool with very few data files other than the ScriptableObject assets (very small) that define the marker types and their settings. I made it this way so Magic Markers -- if you delete its demo scenes and manual from your project -- is extremely small. That way, it can be left in a production build for mobile targets as a debugging tool (e.g., enabled from a developer console) without significantly increasing the build size of the project. But drawing the meshes procedurally takes a lot more resources than having Unity's render pipeline draw normal models.

Fourth, are you using that custom culling code that I provided? In a large scene like this, that will help a lot.

Fifth, your environment looks great in the video. That's not related to Magic Markers, but I had to say it!

It would really help if I could get access to this scene so I can replicate the issue here and do a deep trace into my code. Is there any way I could get access to your project? Is it stored in GitHub or Unity Collaborate, for instance? How large is it, and is it feasible for you to export a Unity Package that has just the pieces for me to run that scene standalone? I don't need the game to be playable (probably), just a small test that illustrates the problem. Perhaps you could make a copy of your scene and then delete out anything not related to the problem, verify that your copy still has the lag issue, and export just that scene for me as a Unity package?

As an aside, I'm still actively working on the new version for which I posted the proof-of-concept screen shots a couple of weeks ago. One of the reasons I'm taking as long with this code as I am, is that your game has made me realize there is a demand for Magic Markers to be more heavily used at runtime, so as part of the new version I am completely rewriting the way I render the markers to make it much more performant in play mode.

 

@Shadowing one other question: How many cameras do you have in the scene, and which of those are enabled for the runtime Magic Markers?

 

Thanks for the reply as always man.
This is lag not during run time.
Nah I'm not using any custom meshes.
I only have Magic Markers showing in scene view during run time.

Ya im willing to make a custom project showing just this issue off. Ya my project is crazy large. 17 gb atm. Its a MMORPG

Hope I answered everything. I skipped the runtime questions since this isn't a runtime problem.

Idk why you say my environment looks great I have everything disabled lol. Unless you watched another video from youtube afterwards.
My environment actually looks like this.

 

Okay, then I misunderstood. You might want to try turning off the Ground In Editor option if you could do that easily, for example by changing a prefab that you use a lot. I've tested with over 500 of the markers in edit mode, but to be honest I didn't have all of those grounding. That could be a problem. If it is, then let me know and I have some ideas to tune things.

I mostly meant that the terrain was interesting. I didn't assume it was a finished environment with stuff disabled -- I assumed it was a stylized environment.

 

@Shadowing A thought occurs to me -- you are the most frequent person posting Magic Marker questions, and your project is large enough that it's impractical to send it to me for analysis. Are you using Unity Collaborate or some other cloud-based versioning system? If so, could you grant me access to your project so I can just maintain a clone locally? Obviously I wouldn't share your work with anyone else and would use the data only to help you with Magic Markers questions.

 

Nah im not using collaborate. Collaborate is only for small projects. of course they have made some changes to that may be for larger projects now but either way my internet is to slow for it.

I figured out that the lag has nothing to do with grounded. I have grounded turned completely off. Also the more magic markers i added the lag worsens.

I'm just gonna send you a test scene of the first planet in my game. Probably can't get to it for a few months though. Until then i just gotta put up with it. when I want no lag I just minimize a magic marker component and it hides them all in the scene.

Later today though I might just create a new project and generate 500 magic markets and see if it lags.
This lag happens when I disable everything in my scene but the magic markers so it should do it.

 

At some point there's going to be MM lag since they're -- deliberately -- procedurally rendered and not just procedurally generated.

I'm still actively working on the new version, which is shaping up to be a major upgrade (but will be a free upgrade for existing customers). Your desire to use a lot more of them than I envisioned in the original design is helping to shape the next version, and I'm experimenting with a new way to render the markers that, if I can get it working the way I want, will make them *significantly* faster. I don't want to go out on a limb this early by estimating what that means numerically, but I don't use that word lightly. I've actually got the rendering part working in the lab, but I'm not yet happy with this change's impact on convenience for the developer. I think I have a plan to fix that, but I still need to code it up and test it.

Sorry this version is taking so long. The introduction of SRP, and the fact that HDRP and URP (formerly LWRP) have been moving targets at the API level, have complicated the development. I still am operating under the assumption that nobody is urgently needing the SRP support -- but if that assumption is wrong, please post here on the forum and I'll start pedaling faster to get the new version out. I much prefer excellent quality over fast release cycles in the tools I buy from others, so that's what I'm striving to deliver here to you.

 

To update, Unity 2017.4 is being deprecated by the Unity folks themselves, at the end of 2019, so future Magic Markers versions will definitely be targeted at later versions than that. Exactly where the line will be is still TBD, but it will be at least Unity 2018.1. I'll continue to have the old version available for a while at least, in case any existing customers need it, but with the next update the Asset Store would no longer have support for pre-2018 Unity versions; buyers would have to contact me to request the archival version.

 

I'd recommend 2018.4 LTS, that way you have another year before another minimum bump is needed.

 

That's where I would love to be, if you and other customers are okay with that far of a leap forward. It would allow me to assume the existence of Text Mesh Pro, nested prefabs, and some of the other goodies introduced during 2018. But I am quite prepared to support as far back as 2018.1 if the community feels it is still needed.

Incidentally, I'm pleased to report that I've made some further progress on the new version, and I now have the custom shader working on LWRP/URP as well as HDRP. The two versions differ only in a couple of lines in the source code, so I am cautiously optimistic I'll be able to make a single shader source file that works on both reference SRP implementations.

On advice from the Unity SRP dev team, who have been very helpful consulting along the way, I am not going to try to generically support "any and all" SRP implementations, but rather to make code that customers can adapt to their own SRP stacks. The Unity devs said trying to anticipate all possible SRPs was technically infeasible given the flexibility of those APIs (which is the whole point of "scriptable"), and they also pointed out that the teams who are building their own SRP implementation from scratch will, by definition, have some serious shader-writing talent onboard and won't need my help in adapting the Magic Markers shader to their needs.

During the next day or so, I'm planning (tentatively) to post some of my thoughts about UX improvements for the upcoming version of Magic Markers, to get your (collectively) thoughts on what would be useful versus what might be a great idea in my own mind but actually counter-productive for users. I still need to refine my thinking a bit first.

 

Ya I'm sure we will get it figured out man. I'm patient. It just sucks im so busy with working on my game i can't stop and give you what you really need to see what im seeing. Cause I did a kick Starter last year people are waiting to play the alpha version. Once that gets out my time frees up majorly.

 

No worries! As an aside, my testing with the new version's rendering is going well, and if it works out the way I hope there will be a substantial performance bump.

 

Thanks man really appreciate your efforts. I added another 300 and now its so bad. Its not just the scene/camera that lags. Its the entire editor. Like clicking on objects in the Hierarchy. So im guessing its lagging the On Editor update?
I haven't tested culling I don't think your asset uses frustum culling even does it? I don't think its a graphics issue though like as in triangles being displayed.

 

I'm really sorry you're having such issues. You're pushing Magic Markers way beyond its design point, but honestly I'm glad to work with you because together we'll make the product even better in the next version. I do have a couple of suggestions for you between now and then, though:

• If you haven't already done so, apply the patch that I suggested here: https://forum.unity.com/threads/rel...isible-gameobjects.506993/page-3#post-4600234 This will likely make a big difference for you. Depending on your Unity version, I can probably create you an enhanced version of that patch that looks at the whole frustum and not just the clipping planes -- I gave you this simple patch first because I wanted to turn your request around ASAP and because I need to look at the more-robust frustum APIs to be sure I can either (1) make a patch that works on all the Unity versions I support, or (2) give you a version-specific patch but know that it matches your version of Unity.
• Take a close look at your console logs in the editor. If you have added any Debug.Log() calls within Magic Markers as we've been collaborating to solve this, please comment those out, especially if they're in any of the update or rendering callbacks. Debug.Log() has to do extensive reflection and text formatting, and it can have a much larger impact on performance than many people realize.
• Open the built-in Profiler in the Unity Editor, with your scene open and showing a lot of markers. Use the Deep Profiling option to drill down and see where the CPU is spending its time, or if there are large amounts of GC. If you find this is not in Magic Markers, then you'll need to take a look at the other code. If it is in Magic Markers, please let me know the specific call hierarchy so I can investigate further.
• Consider the game-specific marker-inhibiting logic I suggested, either in the same post as the workaround patch or in one just before or just after that one. I'd be glad to work with you on designing something that works in your game with the existing Magic Markers version, but I'd need access to your code or at least a screen-sharing collaboration session.
• Along the same direction as the Profiler, take a look at other parts of your code that are on the same set of GameObjects that happen to contain Magic Marker components. If you recall the demo scene that is included with Magic Markers, I have run that demo with hundreds of markers -- in the Debug mode so all of them render -- on my midrange cell phone at 1920x1080 resolution. If Magic Markers is causing the issue, I absolutely want to discovery why and fix it, but let's be sure we're not chasing the wrong problem. The Profiler will tell us this, definitively.

Be assured, the new Magic Markers version will use occlusion culling -- even my current WIP testing already does so. Of course, like any Unity GameObject, the ability to have that occlusion be baked rather than dynamic depends on whether the marker is attached to a GameObject that is marked as Occluder Static.

Thanks for your patience in working through this, and for the fact that you've recognized my help is constrained by not being able (yet!) to examine and test your project. I understand that you're currently too busy to make that happen, but rest assured when you have the time to set this up, I'll act quickly to assist you.