tournamentdan
-
Posts
712 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Blog Comments posted by tournamentdan
-
-
Great work!
-
Very cool how you have implemented this. I remember a thread we had a few years ago talking about these possibilities. Glad you were able to work through the obstacles.
-
Does the "spring" slider joint have any dampening when the wheel is being pushed up? If it doesn't you are going to need to add another slider joint to act as a shock or you are going to have a lot of bounce. Just as in real life if your car had no shocks.
-
1
-
-
8 hours ago, Josh said:
@macklebee Yes
Josh, you should check out a open source steering and other cool things they call Smart Body. It's from a few years ago but could give you some great ideas. It's also from USC so maybe you know them.
-
2
-
-
23 minutes ago, Josh said:25 minutes ago, Josh said:
Do you have any materials you would like me to try?
I am in Puerto Rico right now away from my computer. Let me head home and I can send you several.
-
5 hours ago, Josh said:
I've looked into it, and here is what "PBR" means:
- A texture lookup is used for light reflection instead of a dot product equation.
- A cubemap is always in use, with mipmaps. The "roughness" value in a material or texture corresponds to the mip level to use in the cubemap lookup.
- There's a user-adjustable value for the Fresnel reflection value.
As always, good art will look good and bad art will look bad.
It also means that on the content creator side(for pbr). It is about a hundred times easier to create good art.
-
Have you decided to move forward to PBR?
-
1
-
-
Nice. I thought they were going to keep it with lumberyard. Interesting option.
-
19 hours ago, gamecreator said:
I like that there is a strong, doable solution though I know you (and some customers) would have preferred to be independent from Steam. Since you're already with Amazon, I'm surprised that there isn't a reliable solution through them with AWS or something.
I think there is, but its through their game engine.
-
The zombies have 54 bones - the crawler has 24.
That is more than twice as many bones that have to be cycled through for the animation cycles. Not really surprising that it costs more to run than the crawler.
Other than the run animation where the hands/fingers change position as compared to the other animations, there really wasn't a reason to have separate bones for each finger joint. If I had the fbx version of these models, I would remove those bones to get the skeleton hierarchy down to a reasonable number if I expect tons of them in a scene.
Yes and this is where a LOD system would work great.
-
Disable the shadows on the crawler and see what the difference is when it moves. I have mentioned this year's ago. But shadows do not need updated every frame. Josh not to long ago you mentioned that physics did not need updated as much as it was because people could not notice the difference. Same as shadows. They only need to be updated 3 to 5 times per second. Not every frame.
-
You could have your testers record their game play then have them upload it to YouTube but have it set to private. Then they email you the link.
-
Very nice. Looks great.
-
Good work. This is similar to a university real time engine.
Is the location of the individual vegetation generated when the world is created? Or when a player enters a zone? Or distance from camera?
I ask this because how is this going to work with multi player. Because if it is zone or distance. The placement of vegetation would be dynamic for the first player in that area. Then you would have to do some sort of a placement algorithm check based on which player was there first for each player that comes and goes while there are other players there. Right?
-
The location of each instance will be known right? I mean the instances will not be randomly placed on the terrain as the player walks through the map
-
Me to. 3,2,1
-
1
-
-
Josh, may I suggest that you use the bone rig for characters from the motion capture suit that you bought. I do not have mine yet but there are a few people here that have bought it and we could provide good quality cheap animations.
-
You could use a larger bounding box. Any terrain physics mesh inside the bounding box gets tessellated. Any outside goes back to low poly mesh.
-
I wouldn't use tessellation for the entire physics mesh. I am only talking about close to the character controller. Sort of like updating nav mesh around certain objects.
-
It can't, since tessellation is entirely on the GPU.
Wouldn't it be a good idea to use tessellation for the walkable area of the terrain physics shape also?
If this is not done along with the terrain. Feet,tires, even a whole character in the lying down position will get hidden or hover over the terrain.
-
Looks great. I am really glad you decided to go this route. I know my answers to about everything has been tesselation but it really is the best way to get the most amount of polygons close to the camera. And that is what counts most.
Are you going to give us the ability to change the tesselation factor based on the distance to the camera?
Also can't wait for you to get decals working. This also works great for damage or wounds.
-
The invocation option doesn't increase the number of output vertices. I'm not going to use geometry shaders for this.
Yes. And that is what a tesselation shader is for.
-
So would this system enable the use of mechanics on objects, for example “chopping down trees / regrowth after chopped down” or would behavior like that need to be manually placed.
I plan for it to allow dynamically adding and removing individual instances.
Yes this would be easy to do since each invocation has it's own ID value in opengl.
-
You do not need to have an output as much as 255 vertices. A tree model could be generated by a smaller primative with a geometry shader then use a tesselation shader to use as an LOD from the distance to camera.
Particle Physics
in Development Blog
A blog by Josh in General
Posted
Looks great.