I have a situation where I need to move forklifts freely in space. Therefore I use workers but with a changed 3D graphics (so that it looks like a forklift).
Obviously, the dimensions of the changed grapnics are larger then those of a worker. That couses the (instance of a) forklift intercept with boundaries of other objects which it has to avoid (because, as I understand, the systems still expects the worker to have the same dimensions as usually, i.e. as a human figure).
I am considering several workarounds but I am not sure what is the best strategy now.
Should I (do I have to) change the bounding box dimensions of every single object (or graphics) in the layout? - too lengthy.
(How) should I change (and which) attribues of the worker so that the system "knows" it is larger that a normal worker and has to keep larger distance from objets?
Thank you in advance.
Solved! Go to Solution.
You can use the Barred Area object to reserve an area:
thank you. I did so in the end. Of course it works.
I was just wandering if there were quite many objects in the scene and I had to create a Barred Area around everyone of them then the modelling would be tidious.
Therefore, problably rather a question for the developers, whether it will be possible in future versions of Plant Simulation to change the dimensions of a worker (especially in 3D), too?
Theoretically, you can change a worker's dimensions (i.e. change its graphics to your liking) already but without it having an effect on the simulation. That's not what you asked, of course.
Currently, there is no plan at all to change something regarding the simulation of workers roaming freely. The current way this is done relies on the fact that a worker is, by definition, a cuboid of 80cm x 80cm x 2m. That covers the simulation of a human adult pretty well, and, as you found out, does not fit other cases too well.
The thing is that we need to calculate the worker paths in beforehand (I think we had that particular topic for another reason not too long ago, if I remember correctly). You can get an estimate of the task's complexity by starting to simulate Factory51. Shortly after the start of the simulation, four lines are printed to the console giving a rough estimate of how many data are calculated for the worker simulation. This would need to be done for every worker size in the model, and additionally even on every change of a worker size. Factory51 is a model that is rather optimized regarding its layout for workers roaming freely. If you imagine a model with much less restricted space on which the workers can travel but with a similar amount of obstacle-relevant content, the numbers you see grow in magnitues, effectively bringing a reasonable simulation to a long halt when the first worker tries to move.
Additionally, what you now see as obstacles, will need to take these different worker sizes into account and offer you the visualization of obstacles for different worker sizes.
There are ways to work around some (not all) of the issues I touched here but the general issue is that the application gets more complex and slower for everyone, and the number of uses currently does not justify that yet. This may change though - we've been discussing this (and we discarded it over and over again) in varying depth a couple of times in the past years - but I don't expect to have this changed in the foreseeable future.
I see your application and I understand the expectation pretty well. From a user perspective, what you try is an obvious way to combine different aspects of simulation.
Maybe finally an alternative approach to the issue (I doubt that it actually is useful in your particular case but just to have everything approach on the table that theoretically fits): Assuming that in this model, there are no "real" workers moving around, you could turn the modelling hurdle around and scale everything down to "worker size". Your vehicles would have 80cm in their longest size, and the other objects would be scaled by the factor of 80cm/(actual longest vehicle size). This of course would cause a lot of additional work to do but maybe there is a model in which this is the less cumbersome way.
Thank you Mr. Komarek for your comprehensive answer,
perfect, now I got several hints for possible solutions, as you wrote. I must admit, some of them did not come to my mind in the first place.