A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Assets and Asset Store' started by hiphish, Jul 24, 2012.
Thank you. In retrospect that answer was pretty obvious but thanks for leading me there anyway!
I’m messing with the sliding puzzle example and I want to add another axis to the game’s mechanics so that the blocks can slide on all 3 axises. What do you suggest doing?
The code should work the same, the tricky task will be to actually come up with a good way of moving blocks in a 3D environment using 2D controls. Moving blocks by itself has nothing to do with grids, so I would suggest that you first find a way of moving blocks free-form (no snapping), and once you have that working you can apply the snapping code from the 2D puzzle and it should work the same.
I see what you're saying. I was thinking about using an isometric view to make everything work. Now I understand that it's about getting the controls down first.
I appreciate your help. Thank you so much!
Hi, I just upgraded my app to URP. I’m using a parallelpiped with the GridFramework/DefaultShader. The mainCamera is equipped with a Grid Camera. The plugin was working with no issues before the update to URP. But after the update, the grid is no longer showing during runtime.
How should I modify the defaultShader to work with URP or perhaps is there a specific setting to make it?
Edit: Visiting the sample scenes, none of the grid lines are appearing either. Grids still appear in the scene/editor mode.
I think this is the source of the problem:
The lines do not belong to any mesh, they are generated on the fly during runtime and rendered in the OnPostRender method. You could either wait for URP to implement post processing effects, or use Grid Framework to generate a mesh at runtime and render that one. If you want to use the latter, it's not trivial, but you can contact me via PM and we can work out the necessary code. Generating a mesh from data is also how Vectrosity renders vector lines, so it's not an outlandish idea.
Thank you for the update Hiphish. I’d like a solution, but I think it would better serve both our times to wait for URP to get to that stage instead of creating a bandaid fix.
For now, I’ll just roll back the URP updates. Hopefully they fix post processing first before they make URP the standard.
Hi, do you think this would work for making an oblique/cabinet projection 2d game? I am struggling to find any way to change my grid from something other than iso/hex
Are you using a 2D game project or a 3D game project?
I am not a coder and I bought the asset yesterday because it supports PlayMaker.
I have read the information, watched the videos on youtube and went through few pages of the forum and...
I still can not figure it out how to make the conection between the Grid and the Game objects.
I am sorry if it is really wide my questiion... but after lots of hours trying my best I think it would be great if someone could throw me some light.
What I want to achieve is creating an hexagonal grid (I already have created it and added the Scripts and the Mesh collider) and then placing different game objects that snaps in the already created grid. I really would appreciate if you/someone could help me out in this noobish question about how I should approach this.
The concept it is similar to Chess. A grid with different objects that moves within the grid using mouse clicks.
Thank you !!
You don't make a direct connection between your objects and the grid. What you do instead is something like this:
Get the world position of your object (store inside a Vector3 variable)
Convert it to grid coordinates (another Vector3 variable)
Do some math on it, such as rounding the individual values if you want to snap an object, or add another vector if you want to move the object; the result is another Vector3 coordinates
Conver the (new) grid coordinates back to world coordinates
Move your objec to the new world coordinates.
So if you had a chess game and you want to move the bishop two fields diagonally, you would take the bishop's grid position, add the vector (2, 2, 0) to it, convert the result to world coordinates, and animate the bishop's movement.
This is the basic pattern of using Grid Framework for moving objects in the world. When you write code you can wrap those five steps behind one method to hide the complexity, not sure how Playmaker handles complexsity. I hope my explanation makes sense to you. Let me know if it doesn't.
Thanks a lot!
I struggled but you provided me the guides that I really needed.
Hi there, I have searched quite a lot and haven't found a way to do so. I know it uses GL to draw at runtime but I really don't have much knowledge on the rendering part, but it doesn't matter what I do, it always draws on top of everything? I'm trying to mix it with sprites and it's ALWAYS on top of every single sprite I place in, doesn't matter what I try to change, is there a way to actually use the renderer like that? I think I even remember seeing something like this draws Lines and not Surfaces, but do I require it to be a surface in order to Z sort them for sprites?
Can you please provide me some more information? Are you using a 2D or a 3D project? Can you please provide a screenshot (PM me if you don't want it public)? I first need to reproduce the issue on my end.
I sent you a pm
Plans for Grid Framework 3.0
I intend to release a new major update which will address among other things the grid rendering system. It has been almost five years since the release of version 2.0, and Unity has changed quite a lot in this time. Some of those changes, in particular the introduction of sprites, need to be accounted for in Grid Framework.
This will be a major update which breaks backwards compatibility. Some breaks are necessary, some will simply be me cleaning up minor bumps while I'm at it. But all in all I expect the changes to be small, much smaller than between 1.0 and 2.0.
The upgrade will be free for existing customers since it will be basically just a maintenance release.
Unity is a 3D game engine, it primarily renders 3D game models. There is an escape hatch provided by the GL class, but lines drawn that way appear on top of sprites, even if the sprite is in front of the grid in the scene. This is simply not acceptable, but this way of rendering grids has big advantage over any alternative approach, so getting rid of it is not an option either.
Let's take a step back for a moment. C# is an object-oriented language, and the point of object-oriented programming is interfaces and messages: the program consists of a graph of objects which communicate among each other by sending messages. The important part is not what class an object has, the important part is what public interface an object exposes, which messages it can receive. We can at runtime swap out one object for another object as long as both expose the same interface, regardless of how they implement that interface.
Following that logic, why should there be only one way of rendering a grid? I wish to expose a generic rendering interface and allow users to plug in their own backend of choice. Some default implementations will be included, but users will be able to create their own implementations as well. Here are my planned implementations so far:
The already existing GL implementation
A new implementation which generates a mesh with Lines topology
A Vectrosity backend, which will be basically the already included Vectrosity support, but rewritten
Different backends have different strengths and weaknesses. For example, Unity renders the lines of a mesh with Lines topology always at the same width, and there is nothing I can do about that, but in return you can use all the shader features of Unity and lines will appear behind grids. For some people that might be exactly what they need.
The main change between version 1.0 and 2.0 was breaking the huge grid classes into small grid classes and separate render classes. This has proven to have been a good choice and has allowed users to create their own grids very easily. I know one customer who has created a custom grid which looks like the wires of a guitar (the horizontal lines are not parallel and the distance between vertical lines keeps increasing). I hope that this change will empower users similarly.
No more included examples
Grid Framework comes with a number of examples included to get you started. When I had originally submitted Grid Framework to the Unity Asset Store I was asked to provide an example or two because it wasn't really clear what my asset was doing. Since then the number of examples and their sophistication has grown, and Grid Framework has been established.
Bundling these examples nowadays just adds bloat to people's projects. Sure, you can just delete them (they are all in one common directory), but then you have to do so after each update. For 3.0 I want to move the examples to a separate project that can be hosted in public. It would also allow people to see the API in action before they make a purchase.
Minimum Unity version required
I have not yet settled on a definitive version, but I will certainly increase the requirements. This will allow me to make use of more recent C# features and keep the code leaner.
I do not have any estimate on when 3.0 will be released. The changes to the code are not large, but I have to get the API right the first time. How should the user hook up the rendering backend to the engine? Should I allow multiple backends at the same time? Where should newly created GameObjects and components be added to the scene?
I hope to release 3.0 somewhere during the first quarter of 2021, but time will tell.
I came to check here to see if there would be news about URP compatibility. This update sounds amazing. Looking forward to it.
Version 3 reaching feature parity with version 2
Amazing work. Huge win for everyone.
Instead of Vectrosity, there is an incredible, Zero GC allocations line package that we are using.
Request, can Linefy be supported.
I am aware of Linefy and I would like to support it eventually, just not at launch. The possibility of supporting Linefy (and any other future framework) is why I want to clean up the interface and make it as easy as possible to hook up anything. But I want to keep the scope of the initial release of 3.0 focused on what we already have so I can release it sooner rather than later.
Vectrosity rendering backend
Embracing the Unity package system
Vectrosity support as a package
Git packages or embedded packages? Yes.
Playmaker actions overhaul