Hi, I have almost 0 knowledge of DOTS besides clicking the ConvertToEntity box on my prefabs. Which is what led me here. I needed my terrain grass to be individual objects, which ran ok with GPU instancing, but I heard about DOTS and thought I could try it.
So I enabled that box on my grass and performance increased greatly! Awesome! Kind of… The whole point of having them individual game objects was so I could interact with them, specifically have a trigger collider on one object, that then interacts with a trigger collider on a piece of grass. But now I can’t do that since they’re entities.
I found a 2 year old video talking about colliders, but it seems to interact with all entities with the same components, I need it to trigger a specific entity. In short, how do I do this with DOTS:
private void OnTriggerEnter(Collider other)
{
if (other.CompareTag("Grass"))
other.transform.gameObject.SetActive(false);
}
Looks like the hole is going to be shallow. 6 scripts just for a trigger event. The performance is not worth it for me right now… I hope this get’s massively changed otherwise there will be no adoption… ya I’m a little salty
prolly something like this (dont forget to set physics shape collision response to raise trigger events)
System
using Unity.Burst;
using Unity.Collections;
using Unity.Entities;
using Unity.Jobs;
using Unity.Mathematics;
using Unity.Transforms;
using Unity.Physics;
using Unity.Physics.Systems;
public partial class Test : SystemBase
{
StepPhysicsWorld spw;
BeginSimulationEntityCommandBufferSystem bsecbs;
protected override void OnStartRunning()
{
spw = World.GetOrCreateSystem<StepPhysicsWorld>();
bsecbs = World.GetExistingSystem<BeginSimulationEntityCommandBufferSystem>();
}
protected override void OnUpdate()
{
JobHandle handle = new TriggerEventJob
{
GrassTagData = GetComponentDataFromEntity<GrassTag>(true),
ecb = bsecbs.CreateCommandBuffer()
}.Schedule(spw.Simulation,Dependency);
bsecbs.AddJobHandleForProducer(handle);
}
struct TriggerEventJob : ITriggerEventsJob
{
[ReadOnly] public ComponentDataFromEntity<GrassTag> GrassTagData;
public EntityCommandBuffer ecb;
public void Execute(TriggerEvent evt)
{
if (GrassTagData.HasComponent(evt.EntityA) && GrassTagData.HasComponent(evt.EntityB))
{
ecb.DestroyEntity(evt.EntityA);
ecb.DestroyEntity(evt.EntityB);
}
}
}
}
Tag
using System;
using Unity.Collections;
using Unity.Entities;
using Unity.Mathematics;
[Serializable]
[GenerateAuthoringComponent]
public struct GrassTag : IComponentData
{
}
Edit1:
oh if ur not destroying grass that touches eachother but like a grass mower for example u can do stuff like
GrassTag = grasstagdata.hascomponent(evt.entitya)? evt.entitya:evt.entityb
after testing if the evt entities contains both grass and grass mower tag.
I agree! I keep browsing in this forum hoping that some day DOTS will make sense to me. Right now, I can’t wrap my head around either the example you linked to or the reply below. I can’t decide if it’s just because I am so used to OOP or if I’m just a really bad programmer.
I would say that your approach to try to use DOTS for one, super-performant need is how I would like to get into DOTS. That is slooowly, with one piece of my app making use of it. From what I’ve been reading, it feels like currently it has to be a total conversion to DOTS, which is just beyond my ability to understand!
Thanks I can’t try this second but I have a question before I even start. Since we also need a physics body, like a rigidbody for triggers, does the physics body have to be on both entities? Or just one? And does the physics body have to be on the same entitiy as the shape, or the parent, like they recommend with a rigidbody
If people are struggling with Entities, then the right move would be to first see how you could fix any bottlenecks in existing code using Jobs. These teach how everything works, while accelerating your regular C# monobehaviour games. When you understand Jobs and all that parallelism stuff, it’s not a big leap to Entities as most of WHY there’s boilerplate and so on is already understood.
I just need to render a bunch of vegetation effectively and have them collide as triggers. I completely disagree that it’s not a big leap. It’s like 3 lines of code with classic unity, and a TON of effectively random code for ECS to anyone who’s never seen it, and there’s just no where to learn.
Ok. I reread the error you are getting, and someone who understands Unity Physics better than me will have to help you out. I have my own physics solution called Psyshock which can certainly do what you want. If you wanted to use that instead, then I could help you out.
I know this is going to sound really defeatist, but I think it’s finally time to make the jump to unreal. I’ve used unity for years now, and it sucked me in with the ease up getting up and running, but it really faulters in the end game stage where unreal only shows how strong it is (for high end use). With dots being in development for 4 years now, I don’t see any worth while usable improvements coming anytime soon. And with all the shaky news with layoffs and unity stock tanking, I’m not sure how bright of a future it has compared to unreal. Thanks for the help everyone
The entity physics run in a fixed update loop (by being in a dedicated simulation group) it builds a physics world that basically is the collision state of the entities and cache it. Since you are destroying the grass entity when you find it is possible that having a much higher frame rate for the trigger job could result in your system reading from the physics world that has an old image of the entities. So when the trigger runs you try again to delete your entity that was already deleted.
Your trigger system should probably run in the same group as the rest of the physics using the updateingroup attribute on the system.
Also when having issues with physics there is a dedicated sub forum where you will have a better chance at finding knowledgeable people on that specific topic.
For the second error it seems there is a missing dependency injection in a job but not sure which one since it talks about the copyinitialgomeobjectposition which has nothing to do with your trigger exemple.
But I would advise, don’t go there and start copying the code, before you get the basics idea of HelloCube samples.
Then there is a fundamental question, do you even really need collider on the grass?
Do you need each grass blade to be an entity?
Perhaps problem is different and can be attacked from different angle.
This thing for example, doesn’t use individual objects, but a shader
Your issue here is not the tool. But the approach to using tool.
Jumping to another engine, just because you give up at the start of trying something new, wont help you.
You major issue is trying to bite too much at the time.
You need to get few steps back and start from smaller easier bits, to making sure, you understand these principles.
You can try and perhaps should try different engines. But don’t assume, using different tool suddenly make your issues go away. No game engine is ideal. Each has pros and cons.
Yes, you are lucky that Unreal doesn’t have stocks, otherwise you may would realize, Unity is not alone where stocks were affected in recent months. All tech stocks went down, if you don’t know it yet.
Yeah the op will learn the hard way, and it will be a pretty harsh lesson to be honest. The forum here is used to people bouncing back and smiling shyly though.
Just saying welcome back ahead of time as an optimisation.