Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Author
Message
DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 21st Jun 2012 00:01 Edited at: 21st Jun 2012 00:08
I'm unable to figure this timing stuff out. Maybe Matty H could shed some light on this.

My simulation is running so slow nothing dynamic moves. The mass is the mass of the object's size.

The simulation timing i've tried is:


Doesn't seem to make much of a difference. I'm interesting in learning how it all works. I even tried what Fall out did here:
Which can be found here. That is if the Elapsed Loop time is the time in seconds or milliseconds the simulation has been running.

I thought it would be easier to ask then creating a new thread.

Thanks,

DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 21st Jun 2012 00:19
Quote: "My simulation is running so slow nothing dynamic moves"


What do you mean by this, is the fps slow or is the simulation just running slow but fps is fine?

Is it running slow since you started altering the timing or was it running slow so then you started altering the timing to try to fix it?

The easiest way to alter how much to advance the simulation is by passing the time step as a parameter of the 'DYN SIMULATE' command.

A typical loop will use:
DYN SIMULATE
which is the same as:
DYN SIMULATE 1.0 / 60.0

To make the simulation run twice as fast use:
DYN SIMULATE 1.0 / 30.0

This is simulating larger time steps each loop so will run faster, but the simulation may be less accurate.

The SET TIMING command gives you a little more control over the sub-steps, there is information about this in the help file.

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 21st Jun 2012 00:25 Edited at: 21st Jun 2012 00:29
@Matty H - FPS is fine. Have it set for 60 or 30. It was running to slow so I had to mess with the timing. I'll use that command and hopefully it will speed up the timing.

I tried just:



and I didn't get any change.

Thanks,

DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 21st Jun 2012 01:11 Edited at: 21st Jun 2012 01:12
I tried it and I didn't get change here either.

The reason is the default timing values:
DYN SET TIMING 1.0 / 60.0 / 4.0, 4, 0

This means the maximum it will advance the simulation is a quarter of 1/60 of a second, 4 times. Which is 1/60 of a second. So 1.0 / 30.0 will not work.

Therefore if you change to this:
DYN SET TIMING 1.0 / 60.0 / 4.0, 8, 0
SIMULATE(1.0 / 30.0)

It will then do twice as many sub-steps and you can run at 1/30 without losing simulation accuracy, since the sub-steps are the same size, just more of them.

The other option is to change to this:
DYN SET TIMING 1.0 / fps / 4.0, 4, 0

You then call simulate as normal and it will do 4 sub-steps regardless, meaning you may lose accuracy if you run at 1.0 / 30.0


It's pretty confusing at first, I'm just starting to understand it myself

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 21st Jun 2012 01:26
With Dark Physics I just had to set the fixed timing to: 1.0 / 5.0. It worked perfectly at that speed.

I want to try and get the simulation at that speed because everything looks like a normal speed. I've had problems with any other speed.

This is how I create the dynamic mesh:


It seems everything is correct.

I also set the gravity:


so I can't figure out what I did wrong.

Here is a video showing what is going on:


DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 21st Jun 2012 01:35 Edited at: 21st Jun 2012 01:38
Video is unavailable right now, it will probably become available soon.

Setting the timing to 1.0 / 5.0 is pretty large, the simulation should be running too fast at this speed and it will not be as accurate. It may be the size of your objects, if they are really really big then everything may seem slow?

Why are you setting the density to the size of the object? This is density, not mass. I think there is a command to set the mass of an object.

Anyway to simulate at that rate, this should work:
DYN SET TIMING 1.0 / 5.0 / 4.0, 4, 0
DYN SIMULATE 1.0 / 5.0


EDIT: Video showing now. Can't really tell what's going on, the first thing you should do is turn on the debug renderer to be sure everything is set up the way you think it is.

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 21st Jun 2012 02:07 Edited at: 21st Jun 2012 03:08
I'll turn on the debug renderer and shoot ya another video. If it is density and not mass then what do I set the density to? I think u said you need the density to be + to be dynamic.

I'll try just setting the density to 1.0 and the mass to object size and see if that makes a difference.

Edit: The debugging was to slow to show. There are just a billion lines everywhere. Changing the density to 1.0 and mass to object size still didn't make a difference.

Thanks,

DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 21st Jun 2012 14:06
Quote: "Edit: The debugging was to slow to show. There are just a billion lines everywhere. "


This could be your problem, could you post a screen shot of what this looks like. The debug lines should match in nice and neat with all your in game objects, if this is not the case there is something wrong.

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 21st Jun 2012 20:07 Edited at: 21st Jun 2012 20:08
Here is a screenshot:


Your right they don't match up at all. The objects represented by the lines are bigger then they should be. That is most likely due to this code:


Get Out Alive (Zombie WIP): My latest zombie game I am working on.

Attachments

Login to view attachments
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 21st Jun 2012 20:41
What a mess

You may be doing something wrong when creating your triangle meshes, there is a document on this subject in the help file.

You should always use the debug renderer to make sure everything is actually set up the way you think it is. Do one model at a time and be sure the debug renderer matches up each time.

In your screen shot the telegraph poles look like they might be correct, I can't work out what's going on everywhere else

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 21st Jun 2012 20:57 Edited at: 21st Jun 2012 20:58
@Matty H - What exactly should I do? The code is the same for every object. You said the power poles are working so what could be going on with the rest?

If I happen to find one object that didn't cook/load correctly then what do I do?

Also, where is the documentation I couldn't find the section on triangle meshs that has that information.

Thanks,

DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 21st Jun 2012 22:47
Sorry, there is a 'meshes' example, I thought it was in the docs but it's not.

There is no way I can tell what is happening from that small piece of code. You are best trying each object one by one and when we find one that is not working properly we can deal with it.

Be sure to try the mesh example, there is a chance you may be doing something wrong when creating the meshes and assigning them to objects.

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 21st Jun 2012 23:00
Here is my version:


Here is your version:


As far as I can tell we are both doing the same things.

DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 21st Jun 2012 23:09
I suppose the difference is that I load one mesh and then check to be sure it worked, you have loaded lots at once and it's almost impossible to know which one is causing problems without trying them one at a time.

If you check the folder with all your TMESH files, if there are any of size 0 bytes then you know that one failed. You can also check upon creation 'cook' and 'make' will return 0 if they fail.

I don't think this is your problem though as there seems to be lots of physics meshes in the debug renderer, they are probably just the wrong size, position or orientation. Are you moving/scaling any objects after you create the meshes?

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 21st Jun 2012 23:22 Edited at: 21st Jun 2012 23:30
Nope shortly after I delete the mesh and temp object. The only thing that is being scaled is the Object which is the main one not the temp copy. I don't understand why those objects are huge it might be because I don't scale the temp object too. I'll try that now that I thought of it.

Edit: Just tried it and scaling doesn't make a difference.

I also checked and none of them failed.

Edit: I would guess all of them other then the poles are failing which doesn't make sense because they are all loaded exactly the same way.

DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 21st Jun 2012 23:31
This would be much easier if you find one object that is not working properly, it looks like there are lots not working so it should not be too hard to single one out.

When you do that you will see if it is just scale that is wrong, or whether rotations etc are wrong also.

If it is just scale then we need to know by what factor, I did come across a model once that was always 10 times bigger than the physics mesh. In this case you could just scale the model up by factor of 10, create the physics mesh, scale the object back to normal.

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 21st Jun 2012 23:39
This should have taken care of that then:


It is scaled and rotate and positioned is the exact same spot so I shouldn't have any issues. It still looks like a mess. I have no idea what is going on and my code is fairly simple. Just an FYI the strings$ are read in via file.

DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 21st Jun 2012 23:57
I think you misunderstood, I was not talking about the temp object being scaled wrong, I was talking about the physics triangle mesh, so scale the object, create the mesh, then scale the object back.

But working blind like this is just wasting time, get one model that does not work and we can fix it, I could also try set it up for you if you have no luck.

Trying quick fixes without knowing what the problem is will not work.

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 22nd Jun 2012 00:27
@Matty H - Ooo if that is the case the main object is already scaled and positioned so the mesh should also right?

DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 22nd Jun 2012 00:49
If the object has been scaled and moved before triangle mesh creation then this should work. Only there was one model once that was still out by a factor of 10 and I'm not sure why, you could be experiencing this. The fix in this case would be to scale the object to get the tri mesh the correct size and then scale it back again.

This might not be what's happening though, I can't say it enough try one object in a separate program and see if it works, there is lots of things you may be able to rule out by doing this, it will also then be clear what is happening.

It's late here now, I will check in again tomorrow, hope you have some luck. Most problems in beta testing were from retro fitting physics into an existing program, you should start small, do some testing on your models etc.

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 22nd Jun 2012 02:09 Edited at: 22nd Jun 2012 02:09
@Matty H -

It is weird because the scale is different and so is the position and rotation. It would be extremely inconvenient having to rotate (because for some reason it is rotated at 0 when ever I try to rotate it), position it, and come up with some arbitrary value for scaling it. Dark Physics does everything in one command and allows for saving the meshes as well.

Is it possibly something at your end?



DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.

Attachments

Login to view attachments
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 22nd Jun 2012 15:35
This is strange, but at least we know what the problem is and it has nothing to do with timing

Could you email me the model and I'll try it out?

Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 22nd Jun 2012 17:57
Thanks for sending the model.

This model has its mesh in limb 2. The root of the model is much bigger and rotated also, the limb then makes it smaller and rotates it to get the model you see. Therefore 'make mesh from object' loses all these extra scalings and rotations and you end up with a different looking model, this was the problem.

There are many solutions, this code works(GDK):


But if I was you and the model only has one texture I would make a new object(from mesh), texture it and save as dbo. This would change all the positioning and scaling for your level though so it may not be good for you at this point. I say to do this as DBPro thinks your model is bigger than what it is and it probably is not getting culled as often as it should.

The other reason for doing this is you can then make a box for the physics instead of a triangle mesh. Making a triangle mesh for every detailed object is wasteful and your game will run slower.

Where did you get this model, some of the stuff in your game looks similar to a dextsoft model pack I was thinking of buying, is this where it is from?

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 22nd Jun 2012 18:08
@Matty H - I have a lot of mixed media so it might be from that. I don't know. I know some of those types of models aren't apart of it. I'm using a triangle mesh to be more accurate. That model might not need it but models like buildings would.

For figuring out the mesh I could prob:
- Lock the limb mesh vertexdata
- Check for vertexes for that limb
- If it has vertex data then cook that limb.

Thanks,

DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 22nd Jun 2012 18:13
Yes, that's what I was thinking. I may add a command in the future to check for mesh data and perhaps a command to create a triangle mesh from all the limbs.

Be aware that some object may have mesh data in multiple limbs, therefore you would use the overload of 'DYN MAKE TRIANGLE MESH' which takes a limb, I commented it out in the code I gave you before. This could sometimes be useful as not all limbs may need collision(roof of buiding etc) therefore speeding up your game if you leave that limb out.

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 23rd Jun 2012 01:26
@Matty H - I'll try that and hopefully I can get it working.

Could you check your email? I have another issue with the particles. I can't seem to find anyway to get them to spray in different directions. I would think something so basic would be built into your particle system.

Thanks,

DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 23rd Jun 2012 01:47
I sent you the last email as far as I can see, did you get it?

Quote: "I have added a fluid example for v1.1 which should be available soon. v1.1 also has an extra command so there is no point providing you with the code as you will not be able to run it.

It seems I have made a documentation error for the DBPro version, try this command for the emitter:
DYN EMITTER SET RANDOM ANGLE 1, 0, 0.5 //radians

The docs say DYN FLUID SET RANDOM ANGLE which is wrong and does not exist.

Applying an acceleration will make all particles go in the same direction and is not what you want, this is used for wind effects etc.

You can get them to stick also, try a high viscosity(300). You will need to change the simulation method for this:
//-- Set particle interactions on, slower but needed to get a fluid effect
DYN FLUID SET SIMULATION METHOD 1, NX_F_SPH // 1"


DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 23rd Jun 2012 02:08 Edited at: 23rd Jun 2012 02:09
I didn't get ur email for some reason. Set random angle works. The viscosity didn't do much. I copied and pasted what you gave me and it isn't really sticking.

Here is a screenshot to show u what it looks like:


DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.

Attachments

Login to view attachments
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 23rd Jun 2012 12:34
Do you have the PhysX constants file in your project?
NX_F_SPH should be in there, if not, put it in or just pass 1 into the 'simulation method' function.

It will also depend on the size and spacing of the particles, a value of 300 worked for me but you may need to go higher?

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 23rd Jun 2012 19:28 Edited at: 24th Jun 2012 21:43
@Matty H - DYN FLUID SET STIFFNESS 1, 10 ended up being the problem. It is fixed now. They clump together fairly well. I just need to work on blending the particles together so they look clumped together.

I have a few more questions:
Any ideas how I can remove the edges of overlapping particles or test for overlapping?

Could you setup viscosity so it affects only one or more particles? That way you can test for distance and if certain particles are close together you can just set the viscosity of those particles.

I can't seem to get the particle to have gravity.
Edit: I figure out how to have gravity by removing a flag. The gravity doesn't affect it by much when it is set to -9.8. I increased the gravity and it fixed it.

Is there a way to make the particles run with hardware. I couldn't get the flag to work.
Edit: Is this right?:


I am trying to get a higher rate with a more of a high velocity squirt of blood effect.
Edit:


Thanks,

DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.
DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 24th Jun 2012 21:47 Edited at: 25th Jun 2012 06:31
EDIT: I'm still having issues with timing. The debug matches up exactly and no matter what timing settings are it still doesn't work!

I answered some of my own questions. Here are the questions that still remain:

I have a few more questions:
Any ideas how I can remove the edges of overlapping particles or test for overlapping?

Could you setup viscosity so it affects only one or more particles? That way you can test for distance and if certain particles are close together you can just set the viscosity of those particles.

Is there a way of manually removing a particle from the what is seen and giving it back to the emitter system? Meaning instead of deleting it and having it lost forever returning it to the system.

This doesn't seem to do anything for some reason:


It doesn't matter what I do for the emitter rate it doesn't change anything.

Also, considering the mesh of the object I gave u wasn't on limb 0 it might be a good idea to release an updated version of your load mesh and this time test each limb for mesh data.

Thanks so much for your help,

DigitalFury

Get Out Alive (Zombie WIP): My latest zombie game I am working on.
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 25th Jun 2012 11:43 Edited at: 25th Jun 2012 11:43
Particles



I have recently tested multiple emitters and everything seemed to be working. One thing to note is that each emitter belongs to a fluid and you do not give the emitter an ID number, they are indexed, the first emitter(for the given fluid) is 0 then 1 etc.

With that in mind, does the 2 in your code refer to fluid 2, it should do.

Another thing about the rate, the emitter will only emit particles at the given rate if it has enough particles to do so.

Let me know if that helped, if not, send me some code which highlights the problem, an amended version of the fluid example would be best.

You can't test for overlapping particles, I don't think they ever overlap. You give them a radius and they should stay that far apart. If your objects are overlapping this just means there is disconnect between your object size and the actual particles size, try making the particles bigger?

Quote: "Is there a way of manually removing a particle from the what is seen and giving it back to the emitter system? Meaning instead of deleting it and having it lost forever returning it to the system."


Particles never get lost, they always return to the fluid they were created with. The nest update (which hopefully should be available soon) has a fluid(blood) example and shows how to create a drain so particles are returned when they come into contact with the drain.


Timing

I don't think the timing is bugged as I have recently tested it, also Fallout has variable timing working for his project without any problems.

If you can create a simple timing example to highlight were you think there is an issue I will take a look.


Mesh

I will add commands to make mesh from all limbs in the next update.

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 25th Jun 2012 19:00 Edited at: 25th Jun 2012 19:26
Here is the example:


Let me know if you can get anything by tweaking the emitter rate. I was unsuccessful.

Attached is an example. If found it is working properly with no timing adjustments. That is a bit puzzling considering that I wasn't able to get it to work properly without timing on my main project.

Edit: That just confirms it is something else. I'm looking into it. I think it must be something keeping the object from moving. I did set the damping and maybe if I undo that it might fix it.

Edit: I still can't quite figure out what it was. I'm running all sorts of test to figure it out. I do know it is a glitch in my code and not the timing now. I just have no clue why.

Thanks,

DigitalFury

Zombie Video Game!

Attachments

Login to view attachments
Matty H
10
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 25th Jun 2012 19:34
This line is your problem:



From the docs:

Quote: "int DYN FLUID MAKE EMITTER (int fluidID, float sizeX, float sizeY, float particleLife, int type, int posVec3ID, int rotVec3ID)

Creates an emitter for the given fluid, emitters can share a single fluid although a fluid only has a maximum amount of particles available. An emitter becomes responsible for creating the particles, they are only destroyed of their life runs out or they come into contact with a drain. The emitter can only create particles as long as the fluid has particles available.

Parameters:
sizeX - Size of the emitter along its local x axis.
sizeY - Size of the emitter along its local y axis.
particleLife - Life of the particles.
type - The emitter can either create particles at a given rate or maintain a given pressure. Constant flow rate = 2, Pressure = 1
posVec3ID - ID number of the vector3 containing positional data.
rotVec3ID - ID number of the vector3 containing rotational data.


Returns:
Number of emitters belonging to the given fluid. "


Notice the 'type' parameter, you have the emitter set up to keep a constant pressure, therefore you can't set the rate yourself.

Change it to what I have above and it should work.

DigitalFury
8
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 25th Jun 2012 19:45
@Matty H - Thanks that should do it. Figured out what was causing me problems. I think it is fixed now.

DigitalFury

Zombie Video Game!

Login to post a reply

Server time is: 2019-06-16 19:44:43
Your offset time is: 2019-06-16 19:44:43