3Dski7059

My 2 takeaways are, don't forget to exclude the player as an obstacle and the mesh does not prohibit falling off an edge (you need to create an actual physical boundary). The first was an oversight and the second was a lack of understanding of what to expect with than edge case without physical barriers. I almost forgot to mention not understanding what the orange was all about. A large part of this was, it somehow got very large during one of my experiments, even though I couldn't think of anything thing I did to make it so huge. So, is the user supposed to increase of decrease the size themselves to control the computation of the navmesh?

I just got another update today when I went to go check. You corrected the crash, but the general behavior is a bit quirky, but something one can learn to work with. If a box is selected and face selection is chosen, you're forced to click elsewhere so all the faces are unselected, then click the face you want. In most tools I've worked with, switching to face mode on a selected object only causes face selectors to appear up on the faces without them being selected. In this case, there's just this extra need to click somewhere off the objects to make sure you don't have and object that has all its faces pre-selected, prior being able to truly select the face you want.

Cool! Glad I could help. You must be super busy!

Huge thanks for the explanations! Is there documentation on these details yet... Did I fail to find info I should have found?

Thanks, Josh. Yes, I can see your point with a person, which is pretty much a cylinder. An elongated objected like a car or boat would need some a custom controller : )

The navigation mesh appears to be messed up. The brown bounding box is huge, while the blue mesh ares fits the floor. The player can move outside of the blue mesh area and off the edge of the floor when using the ThirdPersonControls. I'm seeing that the brown bounding area is controlled by the "Tile Resolution", but the player is still allowed to move out of that area. The navmesh also doesn't ignore the Player if its place prior to the navmesh being added/calculated. The redish-brown rect is my player. The blue mesh covered the area fine until it recalculated with my player present.

The third person controls component rotates the player as expected, but first person controls does not. This would make a difference if the player was a ship due to collisions. BTW, the FirstPersonControls didn't seem to work for me at all during an earlier session, but it works now, other than not including rotation.

It would be helpful to have a visual indication in the views as to which direction the camera is facing. Some software shows a cone that also shows the length and field of view, but even a small arrow would be something more than no directional confirmation at all.

You currently have no immediate cue that shows how to delete a component once its added. So, it's somewhat intuitive to right click for context menu. This cause only a "Remove" option to popup someplace other than the mouse pointer. I suggest that you simply add a "-" (minus sign) to the far right of the component label. In doing this, its clear how to delete the component, you click on it and you're done... Much more clear and economical.

There is one other complication, and I'm not sure how to address it... The editor lets you open a map outside the current project. So, you are in effect working with a map outside the current project (the title bar shows this). I can see where this might be useful if you want to reuse a map from a different project. But, I would think it be better to put the editor in a read-only mode and only allow the import of the external map into the current project, perhaps allowing for the option to provide a new map name. It just seems disjointed to be officially working from a project perspective, but allowing the editing of a map outside that project and I'm not sure what it might mess with at the project level. If nothing else its could be confusing unless you explicitly limit the user and only allow them to import the map into the current project. Just my thoughts.

I don't know if this helps, but choosing the Terrain tool bar option didn't seem to be a problem, but selecting it from the Edit menu did cause a crash... Just in case this is a different problem. Steam thinks the editor is still running, so I have to restart my system to access a fresh Steam instance. I actually didn't want to edit terrain, but I was trying to look around to find a way to set the world sky, but didn't see any kind of setting for setting the sky : (

Last night I created a simple scene from scratch to get a feel for that workflow and tool behavior. I am set for beta releases, btw : ) I did see that item selection does occur per grouping if items are place under an empty for organization. I think this is a plus, because selected any of the sub-items selects the group if you're using the view port for selection. But, if you need to make adjustments to a sub-item, you can still individually select them from scene tree. I think the editor should open to the project manager. Currently, the editor is initially opened and it really isn't immediately apparent what project it's open to unless you over at the Project tab/pane. On a related note, I think in would be an advantage to automatically load load the last map saved (or what was present when exiting) for the project the user has selected. I did notice the coordinate display at the bottom right, which is cool. I noticed that if you move the mouse to another view port the coordinates don't update unless you click on the port. I think this is okay and something most folks would get used to, since you do highlight the active view port. BUT, I just noticed that the coordinates don't update for mouse movement in the left view. I think that X, Y, Z should be labelled. If an axis doesn't apply due in the active view port, then may change the value to a dash, asterisk, or "NA". When adding an object (i.e., a box) if the active view port is top, left, or back the object is created at the origin. But, if the perspective view is active the object is NOT placed at the origin, so this is inconsistent and a bit weird. I think I may have seen this reported by someone else.., Objects don't appear to be aligned with the visible grid. It might be nice to have Width, Height, and Depth input fields for the primitive objects inputs that the editor offers. I'm not sure if this a pressing need for imported models. Snapping appears to always be set and if it can be turned off I couldn't find the option. Snapping is great for general construction, but not always wanted for prop placements. This could be very important!... The ability to identify and move the axis, or pivot point, for an object; hinges, joints, or the point of rotation for swinging objects. I'm a developer by trade (Java web dev, but started out with C desktop development way back in 1992. I'm struggling with understanding how all the pieces fit together when trying to create something from scratch, so it will be a lot for someone real new. What I seem to have interpreted is, you need to use, or create your own component using Lua or C++ header. This exposes settings to the editor. You then use the API to interact with the component data. This may, or may not, involve the flow editor, depending if actions/events are defined in Lua or C++. That's my starting perspective at least. A good grasp of this will require most to do a deep dive on the sample project and really work out what's needed for a component, the flow, how to program for events, and then apply this to what's needed for the working game. I'm not seeing any a tutorial specific for tying these concepts together that digestible for a newcomer. So, apart from sharing my observations, my homework will be to figure out how to apply the ideas from the sample project to my own introductory project made from scratch. I hope my list is helpful, and appreciate all the work you're doing on this endeavor! Power on, brother!

Hey, Josh... I just saw that an "empty' was at the bottom of the object options. I could manually move things into that, but it seems that can only be used for organization, because selecting that doesn't select the parts for performing operations. At any rate, this did make me focus on the scene panel and see that you can pick multiple items there, so now that works, but you can't select more than a single item to move them to another parent.

Its not uncommon for similar applications to allow you to rename an object directly from with the scene hierarchy. In UltraEngine/Editor you must go to the field at the top of the object properties to perform renaming. This is just an annoyance. But, here's the problem... There are actually 2 problems... a) if you change the name and click on a different object in the scene panel, the newly selected object is the one that gets renamed. b) It appears that a user is forced to use the enter key to confirm the renaming, but if you do that it acts like you want to add a new object. For example, "Cylinder" was the last object that was added, so it appears in tools. Using Enter for the name change causes the dialog for inputting the number segments for the cylinder. The object selected for renaming in the scene panel is part of a deconstructed wall after a cylinder subtraction, used to create a hole in it. You're force to close the unwanted shape properties dialog to continue. NOTE: If a box was the last thing selected, the dialog is not displayed when hitting Enter on a the name field... Great! If a Cone was the last shape, then the dialog opens to ask for the number of segments for the cone... Not great : (. So, the Enter event must not be isolated to the name. EDITED: The workaround is to click in a properties field instead of using enter to keep the name and not have the shape properties dialog open.

As a side note, in the old Leadwerks, attempting to create a whole in a wall with a cylinder didn't work well at all. The basic operation works as expected in the UltraEngine beta. However... In the process above, the cylinder remains selected and you can move it out of the way, so that's great. But, the wall has been pretty much been deconstructed such that it is no longer treated as a single object that can be moved as a unit. To add to the difficulty, there isn't a way to easily select all parts of the geometry to perform any kind of operation; there's no selection mode that allows you to block select the parts. A possible option would be to create a parent with a scene hierarchy that the children would fall under so that would be treated as a unit, but that option is also not currently present. Both of these may not be buga, because they aren't features that are broken, but I think they're both important features that would be very helpful. It common practice to want to group things in a complex scene. The means to select a deconstructed wall after a CSG operation doesn't really exist from what I can tell, because select all is going to select everything in the scene, not just the wall parts.