Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - cjbruce

Pages: [1] 2 3 4 5 6 7 8 ... 48
I thought that eteks were prone to overheating too easy. But then i was running them at 48v (although iirc they can easily take 48v)
But shouldn't your headbanging verts survive less time?
I am using brushless motors for verts, and unlike brushed they can take higher voltages easily afaik

The brushless motors have current limits. This keeps them a lot cooler, but you have to gear them down to keep spinup time short.

Kix, what voltage/gear ratio are you using for brushless?

The 05June2020 Alpha Builds are up!

Nothing new from the bleeding edge builds that we have previously discussed in the past two weeks.  The big change from the last Alpha Build is that electrical systems are now a thing.  You have to include the following to get a robot to work:

- A receiver.  Each channel of the receiver must be set to the appropriate type of control from your radio transmitter.  Left Drive, Right Drive, Single Throw Toggle, etc.
- At least one battery.  The battery voltage you pick is important.  If you choose too low of a voltage, your robot will be sluggish.  If you choose too high of a voltage, your motors will overheat and burn out.
- If you have a weapon, you will need either a second battery (usually at a higher voltage) or a battery hub (to save weight).  This hub will send power to your drive ESC (usually a 2x60 Amp ESC) and to your weapon ESC (either another brushed ESC or a brushless ESC, depending on the motor you choose).
- You will need enough ESCs to handle all of your motors.  ESCs are either single-channel or 2-channel.
- Motors.  Most robots nowadays use brushed ESCs for drive, but it is up to you.  Lighter motors heat up (and cool down) more quickly

Something I'm curious about: As we already have overheating for bots to disable their own motors, would self-damage be as high as before or maybe just get removed and replaced by overheating?

I envisioned physical damage and damage due to heat to be two separate things. 

1. Overheating is completely avoidable if you are willing to play it safe with battery voltage.  The AmpFlows can run all day at the 24 volts for which they are rated.  Maybe we need to include rated voltage in the motor description so people have an idea of what a "safe" voltage is?

2. Over the next few weeks I am going to take what we have learned about damage in previous builds and rewriting damage from scratch.  Is your fear that self damage has been too much of a factor in previous builds?

We just heard back from the community college.  They won’t be ready for in person tournaments until October.  That means we have some time.  We will put out this as a stable release tomorrow morning, then take our time getting damage, pneumatics, and crushers working properly.

kix, I forgot to ask, but does the new botlab shader keep your GPU cooler?  The new shader should be slightly more efficient.

Now i wonder if we could keep the collision but just make the parts have a hole. Ik roblox has that feature iirc

The hard part is creating creating the correct visual display for the mesh.  Once that is done creating a collision shape is done with a single line of code.

EDIT:  For a physics hole it requires more work, but the hardest part is still creating the visual mesh.

I think the crashing bug is squashed!  Here is the latest (04June2020) bleeding edge build:

[Bug Fix] Fixed crashing bug for spinning weapons caused by an undefined moment of inertia.

You could make all of the surfaces invisible, or none invisible, but you can't make a portion of the surface invisible.  You have to create entirely new surfaces from scratch that conform to the shape you want to remove.  These new surfaces contain many more triangles than you started with.  This involves a lot of complicated algorithms that are really easy to mess up.

The "blur cylinder" that was much-hated and eventually removed was my first attempt at doing procedural mesh creation.  I'm out. :)  tashic's chassis and shape creator is more successful, but these are both much easier to do than boolean subtraction.  I believe it took Blender about 20 years (1998 - 2019) to get their Boolean tool to the point it is today.  The tool is pretty good, but it is still a little buggy.

Unfortunately, no.

Boolean subtraction is crazy hard to do for arbitrary shapes.  It would be awesome to have it though! :)

What about making the part invisible to look like it's removed? I think it might be the same way as how hollow cylinders are made?

The problem with boolean subtraction is that at some point you need to make a new mesh composed of many more triangles than the number of triangles in the original meshes.

The photo below shows an extremely simple example.  The 6-sided cube starts with 12 triangles.  When you slice it with a plane, the resulting 7-sided shape now has 23 triangles.  This gets MUCH worse for more complex shapes like cylinders:

Boolean subtraction isn't impossible to do, but it is very difficult with a lot of edge cases (pun intended).  When you get it wrong you end up with invisible surfaces and shapes that break physics in unpredictable ways.

EDIT: Once the Arena Modding Tool is complete kupatec is planning to switch over to working on the Component Modding Tool (CMT).  The CMT will allow users to create meshes with arbitrary shapes in Blender, an amazing suite of free software with a complete set of Boolean Subtraction tools.  You will be able to create anything you want, then bring those shapes into the game.

I found and hopefully fixed a crashing bug that occurred when you stalled out a spinner weapon.  It would only occur for spinner weapons.

The moment of inertia would temporarily become undefined, making physics forces undefined, making it impossible for physics to determine the state of the robot, thus crashing the game.

Does this fit what you guys are seeing for crashes?

Unfortunately, no.

Boolean subtraction is crazy hard to do for arbitrary shapes.  It would be awesome to have it though! :)

Uh oh.  That looks like a highlighter selection bug.  I'm assuming you are clicking on the turquoise cylinder, but a scale has been applied to it and the highlighter is not scaling correctly.

Removable plate material should work like this:
1. Click on a mesh and select the "Remove Plate" material instead of "Steel".
2. In the botlab the mesh should become invisible.
3. When you go to the test cage, the mesh is invisible and its collider is removed.

We do!

How many people do you think might be interested?  Due to family constraints I can only commit to three hours.  Maybe 8 robots total?  That would give us time to talk about stuff as we are going.

We do.  We just started using Discord last week and it has been great so far.
Nice, so how would we go arrangement wise? Im free this week

This week we are finding and fixing bugs.  Next week I'm building real-life robots.  What about two weeks from now?  That will give me time to figure out child care too.

My laptop gets a bit laggy when doing full-screen recording but it's ok, so yea here's the video.

And if you want bots shown in the vid

This is gold!  Thank you.  I haven't seen the same problems with my robots, but I suspect I'm not pushing them hard enough. :)

I will try to find and fix the bugs by Friday.

We do.  We just started using Discord last week and it has been great so far.

Thank you!  I get it about burnout.  How would you guys feel about a parsec tournament with the developers?  We could come up with a list of improvements while we are at it.

There's a thing I've noticed is the fight is even easier to get crashed.

Drat.  Can you show me how to replicate it?

This build is intended to be the summer tournament build.  CodeSilver, kix, would you mind taking a look at it with an eye for how it will play on Parsec/online?

After this build we are going back into development and adding new features and breaking things. :)

The final(???) bleeding edge build is out before the next Alpha:

This one has quite a few changes, mostly to support particles when you hit things with a spinner.  There are a few performance and stability improvements as well.

[Added] Sparks now occur for hits on Steel, Hardox, and Titanium.

[Added] Shard particles now occur for Wood, Plastic, and Metal.

[Added] Spark and shard particles vary depending on whether the hit was a glancing blow or a solid hit.

[Added] Added UTS for all materials. This is only used for bite. Hard materials are easier to bite. UHMW is very difficult to bite into.

[Added] Spinner hits discriminate between "Good Hit" and "Glancing Blow". Good hits push target in direction of spinner. Glancing blows push robots directly apart. [TODO] This will need testing and tweaking for all softer materials. Right now it is likely that small, fast drum spinners will not be able to damage UHMW at all. [TODO] Damage has not been implemented.

[Changed] Rewritten the Armour Materials List into a more logical order.

[Added] New armours: Cardboard, MDF, HDPE, Carbon Fiber, Expanded Steel, Decoration - Vinyl, Decoration - Faux Fur, Blueprint

[Tweaked] Reduced the default ambient temperature of all motors to 21 degrees. It was previous set for 40 degrees for testing purposes. 21 degrees matches the temperature of most indoor arenas. The reduction in ambient temperature will increase the heat dissipation of motors.

[Bug Fix] Titanium now has the correct density (4500 kg / m^3).  It was previously set to be denser than steel.

[Added] "Remove Plate" material now works!  If you add the "Remove Plate" material to a plate, its collider is removed.  You can now make slots in your chassis.

[Added] Colliders are automatically disabled for certain armors.  These include "Decoration", "Remove Plate", "Vinyl", "Faux Fur", and "Blueprint".  If you set objects to have these materials, everything will pass right through them.  This reduces the physics CPU load significantly for highly decorated robots.

[Changed] Small performance improvements done to the botlab highlight system.  The highlighter is now cleaner looking and more performant. 

[Changed] Check out the cool blue chassis builder!  This was a side benefit of the new shader we are using in the botlab.

[Bug Fix] Fixed a bug where not all of the child colliders in a spinner were being disabled. This was causing problems with some weapons, leading to some spinners being out of balance and not able to get up to speed.

[Tweaked] Default Physics Tick Rate is now set to 300 ticks/second instead. This is based on the game needing to support 8000+ RPM spinners.  The faster you set the tick rate, the higher speed the game will allow spinners to go.  The cost is that high physics tick rates are significantly more demanding on your CPU.  My MacBook Pro can only handle around 300 ticks/second in an AI battle.

[Bug Fix] Motor max RPM is now limited by the physics tick rate in GameSettings. The formula is max RPM = 27 x physics tick rate. This completely prevents the instability that occurs when RPM = 30 x tick rate.  NOTE - This means you need a fast computer to run a 14,000 RPM beetleweight spinner!

[Added] Added warning in spinner telemetry if spinner speed is too fast for the physics tick rate.

Pages: [1] 2 3 4 5 6 7 8 ... 48