wadaltmon
-
Posts
109 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by wadaltmon
-
-
I'm excited to see support for the Quest. Being able to test standalone without having to have it hooked up to the PC would be nice as I do with... another engine that starts with U. It would be good to also support the camera-based hand tracking the Quest can do, but support on Oculus/Meta's end has been finicky for it too.
-
On 5/22/2022 at 2:09 PM, EvilTurtleProductions said:
GameMaker has something what I think might be a good middle-ground (maybe?), seeing as how subscription is often frowned upon especially by Indies:
You can use the tools for free, but if you want to use the publishing tools to build/publish you pay a subscription. This means you don't constantly have to pay while experimenting and means you can explore the toolset to see if it works for you without a paywall. When you actually seriously start doing stuff you pay a monthly fee for as long you need the compiling/publishing tools.
This allows new devs to get their feet wet, seeing as how you try to cater to new devs and Indies this might be an idea. Not sure if it'd be profitable though. Definitely an issue that could keep you awake, I imagine.
I remember back when GameMaker was older (started using it when I was 13, so that's a long time ago now, that was around the time version 8 was coming out), the model was that you could do almost everything with the exception of a few functions that were locked behind the Pro version (most notably all 3D functionality was disabled). The big thing was that you could not create a standalone executable for your game, you had to run it out of the IDE. Maybe that should be part of the Ultra model - let people use the tools to play around, but don't let them create a standalone executable or publish the game without paying the subscription. The subscription basically then functions as the recurring price for distributing the game.
-
1
-
-
Perhaps using Unreal as "the big guys" was a bad idea. Unity kind of fulfills the same role in my comment. I hope your confidence yields some stellar results when this is released.
-
Knowing what I know from working in the software industry (as well as having friends in game development, having interviewed for the roles, and constantly getting emails from recruiters about said roles), the main draw of the most popular 3D engine at the moment (Unreal) is that it has crossover potential. Out of the box, you have something that anyone of any skill level can pick up and use. (Even if this isn't what you're going for, or you specifically market to a skilled/experienced crowd, this is still the case.) While this seems like they're pandering a great deal to children with rich parents who will absentmindedly pay the subscription fee (they are, but that's not the point), they also want a full team to have the highest accessibility to their product as possible. An artist, a level designer, a programmer, and an intern off the street could all open UnrealEngine.exe and have something working within their respective fields within a matter of minutes.
There's also the point that Unreal Engine (Epic Games) knows how to sell itself. I'd hate to see another comparison that clearly shows Ultra as the winner only for someone to say "w-well, it doesn't have Nanite!" These are the types of things that the "little man" tech news channels tend to latch onto, and collectively their reach is great, and largely to those who have about as little knowledge on the subject of game engines as they do.
The point of me saying this is that to attract both the Leadwerks users and the enterprise users, you will likely have to do a lot of work on presenting this engine in an aesthetically pleasing a manner as possible, as well as provide toolsets that can be used seamlessly by those people. I hate the fact that people will defer to their lizard brain and just go to the flashiest coolest thing possible, but I can say it's better to have some semblance of this initially and let people discover on their own how capable your engine is than to try and wow people with the more technical only for it to push people away.
-
Displayed as intended, but once I closed it, Windows Defender recognized it as a trojan and automatically deleted the exe.
-
1
-
-
24 minutes ago, JMKUltra said:
Wow:
Very typical Reddit.
-
In the context of UAK in a vacuum, C#/Lua (though it wouldn't be for me, I just know a lot of people would benefit).
EDIT: Should've added before, if the choice is on the table, I'd rather see the 3D engine before more UAK stuff.
-
7 hours ago, JMK said:
No, the player controller does not use the same physics as normal rigid bodies.
And this becomes the case just by setting the physics mode to Entity::CharacterPhysics (2) and the collision mode to Collision::Character (3)? It continues even when using a different collider than the default?
-
The SetInput function interests me, as it seems like it has a lot rolled into it that allows it to take the place of many lines of code, but doesn't block other functions from working in tandem with it. There are a few functions that it overrules (as stated in the documentation), but it provides acceleration, velocity, and rotation for a character while seemingly also overriding the default physics behaviors associated with force applied to a Model or Entity with a given collider applied. On that note, it also seems that it doesn't give you a maximum velocity; for if I use the SetInput function but also apply an extra force in a given direction, I can give that object a boost for a short time before the force dissipates.
Anyone know of the equivalent code for SetInput? It seems to go beyond just AddForce(), SetRotation(), and/or SetVelocity(). Is it maybe a Move() function with some math to determine things like acceleration?
-
11 minutes ago, Marcousik said:
Not sure if it helps but with 4.6 you could use invisible triggers shapes to detect if the player comes to a wall.
The shaped trigger could in realtime detect the player and change the behavior and the animations.
https://www.leadwerks.com/learn?page=API-Reference_Object_Collision
I think that's what @JMK was referencing above, though directly via the Newton objects rather than through the Leadwerks collision API. Doing it as you suggest wouldn't give me the collision information, though, I believe - I'd still end up having to do multiple raycasts on each side to determine if the player is wallrunning. It seems like with the above mentioned new LW5 functions, I'd be able to know the closest point in the overlapping area of the collision shapes, and enact a single raycast from the center of the player object to that point to get the Face*, find the normal (at least, I'm presuming I can get the normal from a Face easily), and proceed to do the requisite simple vector math to find if the player should be wallrunning or not. Without the API support from the physics system, though, it precludes any avoidance of many raycasts every step (especially if I want to go beyond flat wallrunning and allow them to run on curved surfaces as well - which is a big goal of mine!)
-
On 6/24/2020 at 2:08 AM, JMK said:
If you're a beta tester, the new features are now entered into the new docs system. See Physics > Collider.
I am not a beta tester, but if these functions are in the Turbo/LW5 beta, I'd certainly like to be. Is there a way I can opt in?
-
19 hours ago, JMK said:
If you burrow into the shape class you will find the raw Newton objects in there, which do have a lot of collision test features.
If I create my player's model by Model::Create(), is the Shape associated with that of a known size and type? Can I use that shape?
If not, how do I change the shape of the collision model for the player without making a visible model that follows the player around all the time? I tried making a Shape* Cylinder of a given size, and using playerObject->SetShape(), but that didn't seem to change the collision model - it only created a separate visible model.
-
9 hours ago, Thirsty Panther said:
This thread is a little old and for Lua but might give you a starting point.
This is a bit distinct from my problem, though. Take a look at the wallrunning in Titanfall:
Once you come in contact with a surface, you're essentially attached to that surface for the time being. And this can be done from any direction - right side, left side, front and back (any direction in 360, in fact). I wanted to avoid having to use several raycasts all around the character at all given times, as the performance might be affected.
-
Hello,
Currently, I'm trying to implement a wall-running system, similar to the Titanfall games, in C++. The way I've thought it should work is to create a "cage" for the player (if the player is a cylinder, then create a cylinder slightly larger as the cage) and detect whether it is colliding with/overlapping another mesh, then if so, create an anchor point at the point of collision. Then, I can use a bit of math and raycasting with the normals of the ensuing surface to figure out the direction the player is moving and where they will end up next, but that part comes later.
The main issue I'm having is actually creating these cylinders, and actually finding out the collision information. I can create a model for the player like so:
Model* player = Model::Create();So, if I wanted the player to be a cylinder, I could create:
Model* player = Model::Cylinder(16); player->SetPosition(0, 4, 0); Model* cage = Model::Cylinder(16); cage->SetPosition(0, 4, 0);But this doesn't allow me to resize the objects. Furthermore, I'm wondering if Leadwerks has a way to obtain collision information in realtime on-demand. Is there something similar to the Pick system, allowing me to store collision information to a structure to check the point of collision? How would I change the collision type to make sure that my player still collides, but the cage doesn't?
-
Interesting. So how does it read the different materials individually? Does it just read the different channels per pixel and interpret them individually?
EDIT: Nvm, you literally said that in the first post -
On 6/25/2019 at 11:08 PM, Josh said:
A single image is best for speed because it only requires one texture lookup, and these are a moderately expensive operation. It also reduces you video memory usage, by four times.
What does a single map of this kind look like? I can't find any examples.
-
2 hours ago, Daemoc said:
One other test you could try, although tedious, would be to attach static meshes to each bone rather than using a skinned mesh. Preferably with objects that match the same poly count as the skinned mesh. That would isolate the skinned mesh performance from physics.
@TheConceptBoy I think you've already done this with one instance. Is it possible to parent an existing or newly created model to a specific bone of an existing rig in LW?
-
6 minutes ago, TheConceptBoy said:
Well actually notice how even as the frame rate drops the hand sprint animation pretty much stays the same? Notice the head bob starting way too fast than what I based it off in the debugging (close resembled when I spawned some entities.)
You spawned your gun as a Model* and your enemies as Entity*. If you change that, does it make a difference?
-
1 minute ago, TheConceptBoy said:
As the matter of fact, the more Entities I add, the slower my time critical counters are operating, Like camera wobble that uses wibble = sin(wobble_time) however my player movement speed stays the same, as if internally compensated by delta time. This is bizarre.
I remember you were talking about animation time not being 1-to-1 from Blender to LW. Maybe bone-based animation does not abide by delta time, but the physics system does.
-
43 minutes ago, Rick said:
I don't know exactly what it is about debug mode but don't ever run it and expect good results. It's really bad for that. In VS there should be a dropdown in the toolbar that says Debug and you can change it to Release I think.
Can confirm, ran this project and spawned 33 characters before my frames went down below 30. On debug, I spawned maybe 12 and my framerate went down to single digits.
-
If the argument is for or against separately inputting the various maps, I'd say I'd like to have all the maps separate. Makes it far easier to establish and then change just one if necessary or for testing. Granted, with one Male you'd just be re-exporting one map and replacing that in LW/TE, but you'd have to go through a middleman to mix the exports into one.
-
Is it standard to mix the various maps into a single image? If so, why would that necessarily be better off than keeping them separate?
-
3 hours ago, gamecreator said:
I don't use Blender so I can't help with the rest of your question but yes, Leadwerks supports multiple textures on a single model.
I have the maps themselves already exported from Substance Painter, just displaying them in Blender by basically assigning all those maps to separate objects in Blender (assign each individual object its own set of diffuse, normal, metallic, roughness). So I probably won't actually be re-exporting the maps from Blender, just the model itself will be exported.
So in LW, does each texture that I apply have to be UV mapped to the overall model, or could it be UV mapped to a given subset of vertices on the model after I export it all as a single FBX?
Sorry if I don't use the proper terminology with this stuff; I'm not hugely entrenched in the whole art aspect of games creation.
-
Hi everyone.
I've got a gun object that has been created with Blender, and with textures/maps imported from Substance Painter. It's a single gun, but it's made up of several objects each with different materials and map sets (diffuse, normal, etc.). I've got these imported into the Blender 2.8 shading tab with their own nodes , and I also modified the overall specular value in the nodes too, but that should not be an issue as I think you can modify that in LW's material editor.
I'd like to export the gun as an FBX to use as my first-person view model, and texture it with all of these maps and materials. Does Leadwerks allow me to use multiple materials on the same FBX model? If so, how would I go about doing so?
It is also worth noting I plan on using a pseudo-PBR shader, as seen here: https://steamcommunity.com/sharedfiles/filedetails/?id=401506836&searchtext=Pbr . As such, I have a diffuse map, normal map, specular map (inverted roughness map colors), metallic map, and a skybox map (probably from the default skybox given with Leadwerks).
How Gta 5 traffic system was made?
in General Discussion
Posted
Create graph nodes at each intersection/along the roads' curves. This is oftentimes able to be done automatically with many game engines; although RS's is proprietary, I expect they have such a tool. Give each person a start node and a destination node (or start point and end point, and determine the route to/from the nearest node for each), run the A* or another pathfinding algorithm to find the shortest path from one place to another, save that succession of nodes as some kind of structure on each driver (linked list works best conceptually imo). Do all that serverside for the online play so you always have plenty of processing power. In single player, do that solely for the ones that are visible on screen. Add in some graphical smoothing for the driving so it's not choppy, add in some handling for when you attack or threaten them (start a running away procedure when attacked, after a certain amount of time, assess if there's still a threat, continue running away or go back to trying to get to the destination if not).
That's probably just about the basics of it. There's certainly a lot of little nuances that RS took to make it more realistic. Stuff like using a weighted graph system for allowing pedestrians to run in the street, but not prefer to, perhaps. And I expect a complex state machine to govern their mood, current objective/destination, etc.