All Activity

0.9.6 Initial implementation of the new foliage system is available. To use it, create a terrain, select the foliage tool, and add a new layer. Sync your project to get the new mesh layer shaders. Slope and height constraints currently have no effect. Mesh layers are not yet saved in maps. Collision and ray casting (picking) are not yet implemented. Imposters are not yet implemented. LOD and multiple variations within a layer (sublayers) are supported.

yes!

Was it a reply to your showcase thread?

I clicked Hide on a post I made earlier, purely on accident, but now I don't see anyway to unhide it lol. It was to long a post to simply retype. Any advice ? ty

( UAGC ) - WorkLog #4 Introduction to the combat system. The controller will consist of four combat styles, Hand to hand, melee, ranged and magic. When no weapons or combat items are active in either primary or the off-hand, the system will fallback to the hand to hand combat mode. This mode consists of punches, kicks and martial arts style combat. The mode is heavy configurable and offers enough options to customize for any type of game play, including simulations to arcade hack-n-slash styles. The system is based of user input, left mouse button = left hand usage while the right mouse button operates anything in the players right hand. So for example, if the player has no items equipped in either hand than the system will assume martial arts style combat whenever the left or right mouse button is clicked. Combos - Combos can be preformed by stringing along a certain pattern of left to right attacks within a predetermined amount of time. You may configure as many or as little ( none ) combo attacks as you like. I have made it easy to define combo attacks: In the header of each attack style module you will find a section that looks like this: --->> Combos h2h_combos = {} h2h_combos[1] = "111" h2h_combos[2] = "1211" h2h_combos[3] = "2211" This is the combo table for that combat style ( in this case Hand to hand ). 1 represents the Left Mouse button, while 2 represents the Right Mouse button. So for example, when the player clicks the LMB for a combo timer starts, if the player completes the combo by clicking the left mouse button 2 more times within the time frame - h2h_combos[1] will occur. Each combo move has a unique animation and attack move, as well as a sound. There are 10 distinctive animations for combo's. If you declare more than 10 combo attacks then the system will start the animation count back at 1. So combo 11 would actually be combo 1 animation and so forth. Particles will be added once the game engine matures further. 'Damage done' can be defined per combo attack as well. Damage is calculated ( base damage + combo damage + player level ) - ( contingent value ) * ( weapons defined critical hit determiner ).

So it is. Thanks. It's not in the docs by the way.

It's actually in there already. extern bool SetFileTime(const WString& path, const uint64_t timestamp);

Fixed terrain vertex shader for non-one scales.

Replaced mouse tool menu items and hotkeys with a single menu item called "Next Tool" that can be activated with Shift + Tab. Vertex mouse tool will now make the selected vertex or edge snap to the nearest grid point. Terrain creation properties changed a little bit. Default terrain scale now set to 1.28, for easy brush alignment.

That would be good. Something like Texture::RemoveMipMap() maybe? Would also be cool if you didn't have to restart the game for it to take effect. You would probably need access to a list of materials to loop through... maybe. Or maybe the user should add there materials to their own list so they can identify what textures should be changed and what shouldn't be.

This is currently not a supported feature, but I am not opposed to adding it. It will just require a little extra care because Ultra has a lot more options when it comes to image handling.

SetFileTime() would be nice to have. I want to be able to convert a file to DDS and then set the DDS file to the creation date / time of the source file. That way when I run my converter again it won't re-convert the source file unless it is newer than the already existing converted DDS file.

How do games mange the texture resolution that's used in game? In the options menu you sometimes have the ability to change the texture detail from Low to High. I guess all it's doing is using a different resolution per setting. For example; LOW 512x512 MEDIUM 1024x1024 HIGH 2048x2048 ULTRA 4096x4096 I'm wondering if it's possible for everything to have 4K textures, but maybe on game load / restart you could remove the higher resolution mip-maps via code depending on the setting? Surely they can't have 4 copies of each texture, that'd be an insane hard drive guzzler.

This could also an bug from the model it self. Another model is working fine.

https://www.ultraengine.com/community/topic/64026-tags-and-prefabs/ This must be a new bug, as it is wreaking havoc on my initialization routines.

Ah so it needs to be a float then.

Yeah, in one of my projects I made a wrapper for them. I called them CastToScreen and CastToWorld. Naming them to show what they do will help.

For some reason child entitys from mdl models dont have any tags. Even if they are assigned within the editor.

In this model the pbr dont get loaded correct. Whit windows 3D view everything looks fine Blue.zip

According to my discord post i upload here the model where the problemm happens. https://drive.google.com/file/d/1iqW0j6to9H0XicAe3CFlseViVGf46UN1/view?usp=sharing

z coordinate is the distance in front of the camera.

Yes, I always forget which is which. Maybe these should be ScreenToWorld and WorldToScreen?

I had a guy in the Ultra discord server ask me how to do parkour after I showed a video.. While it's really not a technique to explain over discord, I told him I would post a video and a short description on how I went about doing it. I'm certain there are other methods but I really wanted preformat over drop-dead accuracy. In the video, I attached 2 cubes to the parkour solvers as to better show what's happening behind closed doors. The light blue, or cyan cube is the 'collector' and the purple or magenta, cube is the 'feeler'. What happens here is the feeler tests the area around the player at different update frequencies, it then reports back data to the collector. The collector then decides which data is relevant based off the players location and angle. Once the 'useable' data is determined, it is sent to the player controller where, based off user configurable settings, it is interpolated into an action (hurdling over a box for example). You'll have to pay close attention to see the feeler and the collector in action, the cubes hardly show everything they are doing but at least you'll get an idea. Most geometry sensor systems use up to 14 feelers, while that makes for a very realistic simulation I find it not so practical for game use. I originally was going to use just 'a one pass sample' of the geometry around the player for speed purposes but I found I couldn't do everything I wanted to do with that system. So after reading up on the process I went with a 2 sensor system at little to NO cost on performance. Now that the system is in place I can do a lot more with it rather than just simple vaulting ( as this video demonstrates ), so over the next few months you'll probably see a lot more stuff in my videos based off this system and you won't even know it! Wall runs is on the horizon ! One thing to keep in mind, the map is not staged in any way, this is straight csg brushes made with Ultra editor and dropped into the scene. The system is completely dynamic so there's no extra map configuring required (which is a major plus in my book). I cannot wait until I have time to build a real map with texturing and imported mesh, that's when this system will truly shine I believe, and yes. the system will work with imported geometry. Thanks to Ultra Engine for making this possible! ( and Josh with his emergency bug fixes and API additions. ).

Also screen_position should probably be an iVec3 like is returned by window->GetMousePosition(), unless there's a need for it to be Vec3?