Bleach:Zanpakutou Senshi is a totally free Total Conversation of Half-Life 1. It´s based on the japanese hit Anime Bleach.

  • View media
  • View media
  • View media
  • View media
  • View media
  • View media
RSS feed Report content Sub Collision Box concept (view original)
Sub Collision Box concept
embed
share
view next
Share Image
Share on Facebook Tweet Email a friend
Embed Image
Comments
Darth_Cameroth
Darth_Cameroth

Its cool to here how you're working around these issues. Even though bottom ones aren't a perfect solution, if theres no room for blue lines that's gotta mean its a vast improvement.

Reply Good karma Bad karma+1 vote
eliasr AuthorSubscriber
eliasr

Definitely. But I haven't come up with a creative way to do a performance check yet....

Reply Good karma+1 vote
eliasr AuthorSubscriber
eliasr

I will actually do that as the next thing.

Reply Good karma+1 vote
Death-The-Reaper
Death-The-Reaper

What about making a model with multiple hit boxes instead of one for all so to speak?

Reply Good karma Bad karma+1 vote
eliasr AuthorSubscriber
eliasr

The model consist of 3 brushes and 3 hitboxes.
HL ignores the hitboxes and makes one single BB per model. I played around with the QC file to try to enforce it to use the hitboxes, but it didn't work out for me.

Reply Good karma+1 vote
eliasr AuthorSubscriber
eliasr

While the issue of the diagonal BB will be reduced for 3 seperate BB's there would still be an issue because the boxes are retangular and that extends the BB alot when rotated.

A square of 1x1 is 1.44 in the diagonal, so only 0.44 extra.

For a circle or sphere it would not be relevant as the BB remains the same regardless of the object's rotation.

Reply Good karma+1 vote
Death-The-Reaper
Death-The-Reaper

huh, thats a bummer.

Reply Good karma Bad karma+1 vote
eliasr AuthorSubscriber
eliasr

Thanks for your questions and feedback, it made me look into the performance on behalf of your curiosity.

Currently I have experienced that spawning 200 getsuga (1200 entities) at once isn't quite alright for the engine to handle. Spawning over time i reached 460 before getting the same error.

ED_Alloc no free edicts

Forums.alliedmods.net

Luckly there is a "fix"
Forums.svencoop.com

I doubt we can expect everyone to be aware of this, but it could be a possibility.

Reply Good karma+1 vote
eliasr AuthorSubscriber
eliasr

Practically though the engine seems to get enough around 200 getsuga's, 300 and some lagging will occur on my machine.
So that is some 1200 entities. (getsuga model + 5 collisionboxes)

So keeping in mind of existing entities (47 with 1 player on our largest map) and assuming 100 getsugas active at the same time is quite unlikely (but not impossible), no more than 10 collisionboxes would be recommended.

It should also keep inside of the default allocation size for entities.

Reply Good karma+1 vote
Death-The-Reaper
Death-The-Reaper

ok then, are the getsuga's moving and deleting on impact? and if they are, are the spawned entities actually being deleted or simply left there or no longer registered as part of the active group?

so say on the biggest map its a 10v10 fight, and everybody is just spamming an attack like the suga's, how many would be in the air at once? just how much of the entities use would there be? i do recommend increasing the amount by default if you could.

Reply Good karma Bad karma+1 vote
eliasr AuthorSubscriber
eliasr

Yes, on impact the collision box will call a function in the getsuga. In that function an explosion will happen and all its collision box's will be deleted.

I will go more into depth of it in the upcoming tutorial.

With the limitations of reiatsu and the speed of the attacks, it seems unlikely that the amount should reach 100 unless a very coordinated action by all the players were to take place.
In addition the elements used for debugging will be removed, and as such there won't be a message overflow; this should prevent lagging.

I recommended no more than 10 collision boxes in an attack as 1200 entities seems to be at lot for the engine to handle. That said, it is not equal that the getsuga will have 10 collision boxes. The prototype only uses 5 and it has been promising so far. I need to implement the actual model before I can determine the need for collision boxes.

Reply Good karma+1 vote
Prince_Dragoon
Prince_Dragoon

Awesome to see things are going well.

Reply Good karma Bad karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

Description

To follow up on Update #23 and clarify what is done with the collision boxes:

Keep in mind that this could be relevant for any type of model that can be rotated, as the Axis Aligned Boundary Box cannot be rotated. Also keep in mind that the solution comes with a cost of multiple elements instead of one, and one weight that against the need of precision.

In this image you see 4 shapes, the top are how the Getsuga would look with a boundary box when aligned and when diagonal to the world axis (represented in 2D as x and y), the bottom shows the Getsuga with multiple boundary boxes inside itself when aligned and diagonal to the world axis.

The boundary box is coloured red and the area that would incorrectly be part of the collision is striped with blue lines.

The AABB is fast to calculate and today is often used as a broad collision detection in modern engines. Those elements that collide will then use a more advanced collision detection algorithm to determine if there is a collision or not.

In HL AABB is what you got to work with and when it detects a collision several things happens, including a event call to a Touch function. It is possible to do a more detailed check at this point, but it is not practical to implement a custom collision system in HL.

If the boundry box was able to be rotated we would have been satisfied with that, so the top left shape is adequate for us, this is because the attack moves quickly forward.

However, when rotated there will be a spike in front of the model, this is not okay.

The bottom shows our solution by adding several small elements inside of the model, the model doesn't collide itself any longer. When aligned and diagonal it is only a matter of insignificant spikes that might extend from the model, providing more satisfactory game play.

The blue lines are not on the bottom shapes due to inadequate space to show them - not because they a perfect solution.

Details
Date
By
eliasr
Size
1000×530
Views
88 (2 today)
Options
URL
Embed
Embed Thumb
Share
Feed
RSS feed