I am using Nez and having some issues with the boxcastBroadphase method in Physics. I have create an entity that attaches a collider to itself, like this public Solid(int x, int y, int width, int height) { this.Collider = new BoxCollider(width, height); Flags.setFlagExclusive(ref this.Collider.physicsLayer, 10); this.transform.setPosition(x + (width / 2f), y + (height / 2f)); this.addComponent(this.Collider); }
but when I use this to get the colliders with the same mask, it does not return any of the colliders
this.BroadphaseSolids = new HashSet<Collider>(Physics.boxcastBroadphase(this.camera.bounds, 10));
From what I understand from the documentation, this should give me all of the colliders with the layer mask 10 that are inside or intersecting the camera bounds. If I remove the 10, and just ask for all of them, I get 26. When I add the layer mask, I get none. Is there something I am missing?
yeah, the physics system in Nez isn’t super intuitive. It took me a bit of time to wrap my head around it but now that I understand it, I really like it.
Hey, I am using Nez to make my own Tile Engine and am struggling to get the layerDepth to work when rendering my tiles.
I have one component called TileMapComponent, which implements IRenderable and takes care of rendering all of the tiles on the map through a for loop which calls Batcher.draw(). For some reason, specifying a layerDepth in the draw() method doesn’t do anything, it seems that it only worries about draw call order.
I have found a “hack” to get it working by manually sorting all of the tiles that are at the same position but on different layers and then calling them in order. But then it still doesn’t work with any external entities (say I have a player entity that is on the 1.0f depthLayer, it renders behind the 0.5f tiles simply because it is declared/called before them). I’ve even tried inverting the depthLayer, setting the DepthStencilState, etc. Nothing worked.
So does Nez’s Batcher not support depthLayer? or am I misunderstanding something?
Here’s a video using a simple test RenderableComponent showing the issue.
(As you can see in the video, simply switching the two lines changes the render order even if I have specified the layerDepth as 0.5f and 1.0f, ideally the NotFoundTexture would always render on top).
The only things in my Scene class are these in the initialize() method:
public override void initialize() {
clearColor = Color.LightGray;
addRenderer(new DefaultRenderer());
Entity test = createEntity("test");
test.addComponent(new TestRenderComponent(content));
Core.debugRenderEnabled = true;
}
It seems to me like it’s an issue with MonoGame or Nez’s Batcher, not sure tho.
EDIT: I have also tried setting the renderer’s material.depthStencilState to DepthStencilState.DepthRead but it did not change anything.
EDIT2: Saw that I forgot to change the sourceRectangle parameter for NotFoundTexture in the video, but that doesn’t matter since they are both the same size and position. Question/issue still stands.
Did you enable depth test? Nez by default doesn’t use it because when you use Nez RenderableComponents the “Nez way” (is not trying to write two layers one after another) Nez will sort the calls before sending them to the GPU.
I’m not sure what you mean by “depth test.”
But if you’re saying that (by default/“Nez way”), Nez will sort the draw calls based on depth, then shouldn’t my draw calls be sorted then?
You have two calls happening one after another and you are overriding the layer depth. Nez can’t sort that. Do your two draws in separate RenderableComponents and then it can sort it. Have a look at the Nez.samples repo for lots of examples of sorted calls based on layerDepth and renderOrder.
So what you’re saying is that multiple layerDepth don’t work inside one RenderableComponent?
I was trying to render all of my tiles on one RenderableComponent to avoid creating entities for each tile. Is that just not possible then?
I guess what I could do it is to write some sort of wrapper that takes all of the “draw calls,” sorts them by layer, then actually calls the batcher.draw(). Would that be the only way?
By default, DepthStencilState is set to None. Nez doesn’t use or need a depth buffer because it sorts everything itself. What you are trying to do by just rendering stuff with no specific order requires the depth buffer to be enabled. You can of course make your own Renderer that doesnt sort and enables depth testing. The “Nez way” of doing this would be to just add multiple RenderableComponents on a single Entity if they are all related. Just let Nez handle the sorting and render order for you by setting RenderableComponent.layerDepth/renderLayer.
Alright, finally got it working. I ended up using one RenderableComponent for each layer, and have a main Component that sends the tiles to be rendered to their corresponding layer.
Thanks for all the help (and sorry if I was kind of pushy).
Hey!
After looking more into the rendering code, I found a much simpler way to fix this issue. The only reason why Nez can’t handle the depth layer is that DefaultRenderer uses Material.defaultMaterial, which has its DepthStencilState set to None.
So I created a custom Renderer with this line in the constructor
that was enough to fix all of the issues and for the Batcher.draw() method to accept/use the depthLayer.
I was wondering, do you want me to submit a Pull Request to add this to the DefaultRenderer? Or perhaps add a new Renderer that fixes that issue? Or maybe add it to the docs? Just think it might be useful for others in the future.
That’s exactly what I told you in my previous comment
No pull request necessary. Nez purposely does not enable the depth buffer because it does the sorting itself. The Material system is there so that you can then do whatever you want with your Materials. Likewise, Renderers are all overridable so that you can render exactly how you want to if you choose to not use Nez’s sorting.
I just started tinkering with Nez and I like what it has to offer. Unfortunately I’m having a problem getting it working in an Android project and I was hoping I could get a push in the right direction.
I’ve got a solution with a Shared Project, then a DesktopGL project and an Android project with references to the shared. I’m able to get a simple scene with a single sprite running in the desktop version, but I’m getting a runtime error while debugging the Android project, right after the MonoGame splash:
Unhandled Exception:
Microsoft.Xna.Framework.Content.ContentLoadException: Could not find ContentTypeReader Type. Please ensure the name of the Assembly that contains the Type matches the assembly in the full type name: Nez.BitmapFonts.BitmapFontReader, Nez, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null (Nez.BitmapFonts.BitmapFontReader, Nez) occurred
Results are the same when referencing the .dll directly.
I pulled the latest commit for the follow camera, but I’m still getting the jittering issue others have reported when using it at low resolutions (480x270, 640x360) it isn’t until I get to about 960x540 that it starts to smooth itself out. The lag is still there at the higher resolutions, it’s just not nearly as noticeable
After digging into this for much of the morning, I’ve narrowed it down to being present when using TiledMapMover. Using a regular mover results in super smooth camera movement, using the TiledMapMover is very jerky. I see a commit to TiledMapMover a few days ago that was to address adding subpixel movement, but it was reverted a few days later… not sure what that’s about.
I’ve been unable to narrow down the problem further, or fix it… I’m giving up for now and hoping someone else can at least chime with with ideas.
Don’t misunderstand me, I think it’s an incredibly complete and amazing framework that has a plethora of features, functions and helpers and I’m by no means implying anything is missing, lacking or in any way incomplete and it’s definitely being maintained… but I am wondering if there are plans or ideas to make it even more awesome in the future with additions, improvements or new features (not that I even know what those would be…)
The core of Nez is fairly complete. I don’t think it will ever be 100% complete, but at this point it’s pretty solid and very flexible. For example: out of the box, the renderer can be used in standard forward rendering, deferred rendering, multi-render target blends and pretty much anything else you would want to do. This was all added with no changes to Nez code.
As for Components to build on the framework itself, there are always more that can be added. Anything that is not game-specific for example would be a good candidate. Most Components are usually game-specific though so they wouldn’t work as building blocks in the engine proper.
For anyone interested, Nez now has a dedicated Discord channel. It’d be awesome to get some participation there to discuss the framework in detail, cover different implementations and problem solutions, show off work, help each other work through problems and discover some of the more “hidden” features and maybe discuss how we as a community might able to help contribute to the project.
