Josh

Well, yeah, you can do pretty much anything as an extension. So you are saying that if I was to choose one way to do this, you are usually loading mesh colliders (static), not convex hulls?

There is a "browse" option in the collider drop-down, but you raise a good point. The current design follows how mesh materials and material textures work. With those items, there are multiple files that might be applied to one asset in one window. However, with colliders there is only one collider per model. So that might be a justification why a menu item for the window is the better option. I'm dragging my feet on your request to load colliders directly from models because: Colliders loaded from models could be a Newton tree collision (mesh) or convex hull(s). Convex hulls have a tolerance value to control exactly how precise/detailed the hull is. Collision trees have an optimize parameter to control whether adjacent faces get merged. These options are all available in the current interface. In order to support them in a model loading step, I would need to duplicate all this functionality in a new interface. It is strange to implement the same feature twice.

You can open an OBJ file in the asset editor and create a convex hull from that, then save it to the file you want.

1.0.3 Scene browser search bar now works! Use this to filter all the objects in a map. This is something I wanted in Leadwerks, but never did. Asset editor animation panel / status bar / progress bar consolidated into a single panel that changes based on program state.

It's for comboboxes, listboxes, and treeviews. event.data is the item, or event.extra is the treeview node.

1.0.3 New channel added. Uninstall 1.0.2, then switch to 1.0.3 and install to use. Editor now available, includes everything except the actual scene editing and flowgraph. I believe everything else is finished.

A forward declaration should work, as long as you are creating the object as a pointer or shared pointer: class MyThing;

I stopped using it because it's not cross-platform, and it's really hard to navigate to. Program data is the intended replacement. I'm storing all the engine settings there.

Why not store this in program data? Are there really going to be multiple users on a computer your game is running, who each play the game and want to make sure their saves are stored separately?

I haven't been blogging much because I am making so much progress that there would be too much to cover. In this article I will talk about one little system I spent the last week on and show the improvements I have made to the workflow over Leadwerks. In the asset editor, when the root of a model is selected, a "Collider" field appears in the physics properties. You can use this to quickly calculate and apply a collider to the model. The convex hull collider includes an option for tolerance. You can adjust this to get a more or less precise convex hull around the model: There is also an "optimize" option for the mesh collider. When this is activated it will attempt to merge adjacent coplanar polygons into a single face, and can result in fewer seams on colliding faces. Two new shapes are included, the capsule and the chamfer cylinder, so now all the shapes supported by Newton Dynamics are available. (The chamfer cylinder is good for vehicle tires.) Unlike Leadwerks, you no longer need to specify the axis cylindrical shapes are oriented around. The editor will calculate which bounding box axes are most like each other, and use the third axis to orient the shape. This works for long skinny objects: And it also works for short fat objects: It will even detect which direction a cone should be facing, by calculating the total distance from the shape the model vertices are with each direction, and selecting the orientation with the smallest error value. (A single cone is probably not the best choice of shape for this model, but the point is that it correctly guesses which direction the cone should point based on the model vertices.) For more advanced geometry, the convex decomposition tool is available in the Utilities panel. This exposes all the parameters available in V-HACD 4.0 and processes the task on a separate thread so you can continue to use the editor as the task runs in the background. It usually only takes a few seconds to compete, but it is nice to not have your workflow interrupted: You can export colliders as model files, so it's also possible to just use this to generate convex hulls and export them to .obj. (I could get a better fitting shape if I spent more time adjusting the settings, but I just quickly made this shape with very low settings in order to get this screenshot.) The new .collider file format, like everything else in Ultra, is JSON-based. Simple shapes can be stored in pure ASCII text, so they can be edited by hand if needed: { "collider": { "parts": [ { "offset": [ 0.0024815797805786133, -0.18715500831604004, -1.055002212524414e-05 ], "rotation": [ 0.0, 0.0, 0.0 ], "shape": "BOX", "size": [ 1.8899539709091187, 2.0, 1.8019688129425049 ] } ] } } More complex shapes like convex hulls and meshes use binary data appended to the end of the file to store their contents, so that they load quickly in the engine: { "collider": { "parts": [ { "data": 0, "shape": "CONVEXHULL", "vertices": 61 } ] } }�n�2��<�5�j�k��#�I3��ch�������=b[��I<��~d�I�D�` �[�\{4���A���?XO3���>��վ�v!���f��� ?]����I�!�����V� >�?���mdG�t9�a��@���X?W��0o��e�-�D��h�P?>����>��׾���@��=T�U?��ž�{����w�� ���G��3��ޑ?>V?c�����;���6�s�/?&�=����?q�e?j��N���[#b��bݽ(��>��Ǿ�ڽ�E��MV�ַؽ��8<�G������D?BYT?I���@"N?6?�";-�$?��콜�";��t>8�"�t�";�z��3�0���";����ݐ�)�%=}P?��0?���=/�E?BYT?'>�=�E��MV����={; ?"����>�־��c� �>��?q�e?�$>�ӽ��P��@>��,?�j|=�2�>[o/���P�C��>��?>V?Z�>�������Қ�>��h���@�>��E�CO2��.�>T��[A�y]�>L��=T�U?w4�>���>�쾛?#o��e�-�r?�����U?�"?.�v>��!?�R?�zv����>�@?(�0�S �>.(?�n_�C�?�|-?d�[��}?��4?��>��վ��6?2M4��*?�>?P��=_�s��F?V ���ྲAm?�#�I3�Lr?����� Leadwerks .phy collider files can also be loaded. Notice in the shots above, in the drop-down menu there is also a "Browse" option, so you can create a collider file with a low-resolution model and then load the resulting collider to use with a high-resolution model. I think this design strikes the right balance to let you do simple things quickly, but still allow for more advanced options when you need them. In the future I would like to add an additional in-depth collider editing utility that would allow you to select each sub-object, select model polygons and generate shapes just from those polys, and other advanced features. The pick mode feature has been revised. The original design was based on Blitz3D, which did not support collision primitives at all. Instead of specifying a sphere or other shape for picking, you can now just tell the entity to use the collider for picking. (PICK_SPHERE is removed.) On an unrelated note, I had to adjust the camera range based on the distance from the model being viewed, in order to make very small objects visible. This allows extreme close-up shots like in the blog header image that you probably aren't used to seeing except in VR. It's kind of interesting.

Site traffic tripled since the above announcement.

Just compiled a new project made with 1.0.2 and VS 17.5.5. Maybe you just need to clean the project so everything rebuilds, or update visual studio?

I'll have an update out soon...

I want to focus on the editor first because any changes I make to the GUI system could affect this issue, rather than the reverse.