[RELEASED] Snap-and-Plug: join anything to anything

.

 

This is configurable a couple of different ways.

In the next version it's a LOT more obvious how to change this , but msg me on Discord and I can work through with you what option is best for your current setup.

Do you mean in script? Briefly: get a reference to one SnapSocket, and a reference to another, then call:

[firstsocket].SnapTo( [secondsocket] );

...off the top of my head you don't have to supply any options, the defaults work OK.

In current version: it's possible but requires extending one of the existing classes. I haven't done this for over two years

In next version: it's very easy, you just plug-in a custom 'control the position' module.

That's an interesting idea for a feature! Right now it would require some hacky code (you'd have to create fake-sockets somehow), it would be possible but probably very difficult.

But I'd like to try adding that to the major upgrade (next version) I'm working on at the moment.

NB: the "next version" won't be ready for a while yet, there's a beta of the 2D/core-3D parts, but I'm currently working on fixing all the VR parts.

 

For anyone else wanting this (Change the snapping-distance), if you're using InGameSnappable (you probably are!), the change is easy to do.

In the file "InGameSnappable.cs", right at the top, is this section:

Code (CSharp):

1. public virtual DragDropAction3D CreateNewDragAction()
2.    {
3.        //e.g. 3D world snap: return new DragDropBlockAction3D( materialForPreviewGhosts, DragDropSnapMode.METERS_3D, 1f );
4.        //e.g. 2D screen snap: return new DragDropBlockAction3D( materialForPreviewGhosts, DragDropSnapMode.PIXELS_2D, 15f );
5.        return new DragDropAction3DWithGhost( materialForPreviewGhosts, DragDropSnapMode.METERS_3D, 1f, draggingRemovesFromGroup );
6.    }

That number - 1f - is what's setting the snap distance. Note: you can also switch it to use pixels instead of 3D distance (see the comments there for how).

Also note: this only applies to the current version in Asset Store - NOT the beta (the beta / next version handles this in a slightly different way). If you're one of the beta-testers and want to do this it's probably obvious , but if not - message me for instructions.

 

August 2021 Update:

NB: these are updates for the in-progress work on a major new version, these are not included in the current AssetStore release

• Beta version has been in use by a few testers for over a month without major errors (althought lots of new bugs found that I've been fixing on)
• VR build coming soon for beta-testers (working on my local machine, but needs a lot of tweaks still before it's useable by anyone else)
• Inspectors now upgraded to use the new UIElements/UIToolkit (currently very functional - see below for screenshot)
• In-built Material + custom rendering support for dragging / ghosts / previews (see below for screenshot)

New Inspectors (basic mode):


New material-based ghosting, with support for shadow-modes, transparency-modes, etc:

 

I' m currently making a mobile app where people can create sculptures by snapping objects together, and then place these sculptures in AR.

Snapping objects together works fine, but the users also need to be able to rotate the objects around their snapping points. Similar to a ball joint you find on camera tripods.

There's a Rotatable Joint demo in the latest version on the asset store, but the InGameRotatableSnapPiece.cs file doesn't contain any code. I really hoped that this demo would solve my problem. Can you send me a working version of that demo?

 

Is the demo scene not working for you? That sounds like a corrupted download from the Asset Store - this happens quite often, it's a bug in Unity.

I have completely rewritten this code for v3 to make it easier to extend and use directly in the UI, but it should be working fine in the live Asset Store version.

 

The demo scene in the asset store version (2.3.3) doesn't seem to work because it doesn't contain any code.

 

I'm away from my desktop at the moment so I can't check but the main thing to do is run the scene and look at any error message output to the console - if you can't see an obvious fix send me the errors and I'll look into it. There is no specific reason why that component needs to have any code, and I can't remember if it's used at all. If the file isn't blank then it's probably correct.

 

There are no errors, since that demo is not finished. There are two GameObjects: a cube and a weird-cog-thing. Both have a universal socket so I can snap them together in the editor. It is however not possible to snap and rotate them in Play mode, which is what I need.

If you have fixed this in v3, can you give me access to that version? I'm on a really tight deadline for this project.

 

I re-tested on a virgin project, and it's not working - some of the scripts have got deleted from the plugin. The scene was definitely working last year (several people used it as a base for doing their own rotations), but at some point (probably the latest release) something went wrong - I suspect Unity broke the connections between some of the ASMDEFS (there's various bugs in Unity 2019 related to this) and I didn't notice when I was testing/uploading - sorry!

Best to email me - v3 isn't ready to release yet, and although I'm using it in some of my own projects there's a lot that has changed. The core ideas are the same, but now most things have moved from code to UI/Inspectors, and it's best if you give me detailed info on exactly what you're doing so I can work through it on my end and check it's going to work on your project, and patch any things that aren't upgraded / ready yet. - support at snapandplug.com

 

Is this Project still maintained and or is it dead? Does this project work in combination with ARFoundation/Vuforia.
I am thinking about using it but I dont know if it is still maintained.

 

Maintained - absolutely, yes - but 95% of my focus right now is on getting the major new version ready to go live. There's quite a few people using the beta, but it's a lot more powerful than the assetstore version and so it's also more complicated to use -- I want to polish it until it's the opposite: much easier than the current version (while still being ALSO a lot more powerful).

ARF/Vuforia -- some people have used it with them (from my support conversations with them) but I don't know who's actively using either right now. If it works with the asset-store version - great! - if there are small problems -- I'll fix them and patch the assetstore. But if there are medium/big problems I'd push you over to the beta, because it has so much more in it, and it's much easier for me to make big fixes/additions there.

TL;DR: you might want to hold off until the next big release (I've given launch estimates for this going back to the start of Covid, but it's been a crazy pandemic and I keep missing them, so I'm not going to make any more promises until it's actually submitted to the Asset Store). Or get it now, try using it, give feedback (because there's still time for wishlists / requests to make it into the new version!), and you can upgrade to the new version when it goes live, for no more than the difference in price if there is one (i.e. I will ensure it won't cost you any more than it would have to have delayed).

 

Finally added a feature I've wanted for a loooooong time: automatically creating SnapSockets from the FBX/imported model itself.

NB: this isn't magic - it can't guess which sockets you want! - but now you can store your Sockets directly in the .blend/.FBX/etc file, have artists make them line up perfectly (using your 3D editing software), and then when you import to Unity, SnapAndPlug will discover and use the positions+directions.

This will be in the 2022 new version, it uses a lot of the new code (you may notice that the Inspectors look a lot different here!)

 

In generall:

Is there a method with which I can Snap to sockets together?

 

Yes. Current version it's the "SnapTo" method (with a couple of variations) in the SnapSocket class - you need to provide a second SnapSocket reference (the target socket, on the target GameObject) and there's a couple of optional parameters that are a bit confusing to use.

There's also methods for snapping the objects without actually connecting them - i.e. moving the current object into position, but no other changes take place (allows you to line-up snaps then make a separate decision about whether or not to commit to the final join/merge).

...

In the new version (in development) this is greatly improved: the SnapTo method works more obviously, and all configuration is handled by separate modules, with example modules for all common use-cases included. If you need to do scripted snapping in a big way then you might want to wait for the new version to launch, because it makes it much cleaner (and fixes a lot of strange edge-cases where the current version tries to snap correctly but makes incorrect guesses).

 

I am sorry, but the method SnapTo is not shown in the scripting documentation. Is that normal or can you send that to me?

 

Email me - support @ snapandplug.com - and I'll rebuild the docs from current assetstore release and send them to you, if there's anything missing I can then correct it.

Here's the header for that method call copy/pasted from my repo:

Code (CSharp):

1. /**
2.          * The main method for SnapAndPlug: snaps two sockets together (by moving the SnapPiece and/or SnapGroup so that
3.          * the two SnapSocket's fully align).
4.          *
5.          * @param stationaryDoor the socket you want to move this one onto
6.          * @param makeConnections defaults to true. If false, the sockets are moved but not connected and you must manually call ConnectWithoutMoving.The only time you should disable connections is when you're making a "preview snap" for the user, but
7.          * don't actually want the connecting-part to be finalised until the user confirms.
8.          * @param defaults to true for legacy reasons - snapping pieces are REMOVED from their snap-group; preferred behaviour is that they MERGE snap-group - this will default to false in a future version
9.          */
10.         public bool SnapTo( SnapSocket stationaryDoor, bool makeConnections = true, bool removeFromOriginalGroup = true )

NB: 'stationaryDoor' is a hangover from how old this code is, this method was originally written in the v0.5 build of SnapAndPlug, when I was taking my proprietary dungeon-builder game and converting the tech into a standalone asset . The new version has removed all that cruft - the names are rewritten to make sense

 

any news about the new version release date?

 

Currently on track for an early-access / commercial beta release in May.

It's 'useable' right now (works fine in my simple demo scenes), but I'm pretty sure you'd run into bugs as soon as you use it on a real project - so I've got a lot more testing and fixing to do.

 

Noticing the asset is deprecated, is it going to continue to be supported? Will we have to buy a new version? I just purchased last week and wondering if I'll need an upgrade or refund. I am looking forward to using this asset, so I hope support is continued.

 

Nothing has changed - I just wanted to prevent anyone from buying it for the next couple of months while I prepare the major new release. Unfortunately this is the only realistic option Unity gives me for doing that (the alternative is for me to set the price to something like $99,999 and hope no-one is insane enough to buy it , but Unity support would probably block me if I tried ).

 

Oh that’s great news, I was scared! Looking forward to the update

 

Finally a new version is coming.
Looking forward to going online soon.

 

Future buyer very interested in the snap system as other utilities out there for realtime use don't fit my need.
I REALLY don't want to jump to unreal engine and abandon what I've put into unity, and your product was something I looked at in the past, but hadn't bought yet. Please let me know as soon as it is available!

 

Has this project been a victim of the declining Unity usage?

 

This is very much still in progress, it's in the "final 5% of the work takes 90% of the time" phase.

But ... it's also been massively slowed down by Unity's own screwups with the assetstore, which have made all my asset work hugely delayed, and created lots of headaches for myself and the other Asset publishers. The private forums and community groups for asset publishers are full of this - but mostly we're not talking about it in public because everything we have to say reflects badly on Unity.

Briefly: Unity made some bad decisions on the assetstore many years ago, we've been advising them to change it for years and they didn't care enough. Now with AI/ChatGPT/MidJourney they are getting bitten in the ass -- they are drowning in the number of spam / bot-generated asset submissions.

There are obvious solutions. Unity as an org is so far unable/unwilling to do any of them. We've all but begged them to do something - anything! to fix this. But right now Unity is delaying updates of assets by months for everyone except a tiny group of unfairly 'blessed' publishers who are bypassing the official publishing contract.

... so I've lost a lot of time walking my other assets through the update process, and I've had to spend a bunch of time exploring alternative ways to distribute assets, and I've had to change plans on how I was packaging the new Snap-and-Plug. It's a big mess, it's all in Unity's court to fix, but we (as publishers) are all having to find ways around it. Ugh.

 

Thank you very much for all of this!

These kinds of insights are imperative to understanding how and what commitment a mere user should make to various endeavours with Unity, and in terms of Asset Store purchases. From a mere user point of view, it feels like the compounding problem is a long, progressive reduction in the number of active Unity users, too. And a side effect of all this, a progressive decline in the confidence in Unity as a platform upon which to build. It's beginning to feel like a gateway product, wherein users aren't likely to commit to Asset Store purchases anywhere near as speculatively as a few years ago.

Which all boils down to this... how is it worthwhile to do what must be staggering amounts of work to make something like this, promote it and support it?

 

I used to work in AAA game development, I was one of the many small cogs in the machine. I lose money on my Unity work but I do it because I still enjoy making games/games-tech/game-engines.

The less money I lose == the more time I can spend on adding new features, increasing performance, etc. So I try to increase the sales/revenue of my Unity work, so that I can spend more time on it.

... but I can afford to do this because it's not my sole job, and I get paid a lot more money in my day-job (outside the games industry). I considered joining Unity a few times, but traditionallly they underpay all their normal staff (everyone except the execs) even by games industry standards, and I simply couldn't afford it.

 

It's pretty much impossible to fully express how grateful I am (and likely many others are) for your forthright forum posts. It's a great solace to see a far more capable, experienced and wise user explain pain points of Unity usage with exacting precision and some gentle but nuanced humour. It's akin to a "tragics" club, providing that needed reality check so we can keep going. THANK YOU!!!

 

1. Increasing the "magnet zone" is possible, and in the next version, it will be much easier to configure. Reach out to me on Discord, and I can guide you on the best option for your current setup.
   
   
2. Yes, you can connect two modules after instantiating them without dragging or using the InGameSnappable script. Simply get references to the SnapSockets of both modules and call the SnapTo() function. The defaults should work fine.
   
   
3. Currently, dragging by two axes instead of x, y, or z requires extending one of the existing classes. However, in the next version, it will be much simpler with a custom "control the position" module.
   
   
4. Snapping a model to the ground, like placing a tree on JRS terrain, is an interesting feature idea. Currently, it would require some complex code, but I'm working on it for the major upgrade in the next version.
   

Please note that the "next version" is still under development, and while there's a beta available for some parts, the VR components are still being worked on.

 

Xmas 2023 updates:

As a test for the current features, I used the latest in-development builds to make an in-game visual-scripting for Unity (video below). This is using both the core 3d snapping and the Snapping APIs to automatically trace the 'flow' of the blocks as a simulated script:

​

To get the main asset launched ASAP I'm looking at doing an 'early access' release in Jan/Feb 2024, which won't be complete, but will be a reduced price and enable me to get it live much sooner.