Performance issues with entity path

CesiumJS
#1

viewer.entities.add({
position:position，
path:{
show:true
}
})

The data length is about 150000. The time span of the data is about three months. After adding, FPS becomes 2fps. I try to set path resolution (12 * 60 * 60), But It is useless. The same data is added with primitive ，The Performance is so good. About 60Fps.But the data coordinate system is Cesium.ReferenceFrame.INERTIAL.The path changes over time! What should I do?

#2

As with all things when performance is an issue in Cesium, don’t use the abstracted scene.entities API, but look into creating and controlling your own primitives through scene.primitives;

Cheers,

Alex

#3

The path is dynamically updated according to the time, does cesium provide an API to obtain all the path coordinates at the current time

#4

Sorry, not sure what you mean by that? Are you saying the path changes all the time? Real-time? Now and then? How often? If you’re creating a primitive, then you are in charge of the update on those primitives. The entity API otherwise does a lot of that for you, but with a performance penalty if you’re doing things the API wasn’t designed to do.

Are you using dynamic properties for the path positions, or just a static array at creation which you manually update by entity.hierarchy = newPositions from time to time? What are you doing in terms of code?

As with all things Cesium, try to make a Sandcastle that replicates as close to your issue as possible to make it easier for us to understand what you’re doing, and try out various ways to help you further.

Cheers,

Alex

#5

I’m really trying to implement entity function with primitive, because the performance of path is too low, so I want to implement it with primitive. Data changes in real time, not fixed

#6

I saw the source code of path, and now it has been solved. Thank you very much

#7

I have been dealing with the same kind of performance problems using path. Would you mind sharing tips about how you solved your issue ?

Thanks,

Clément

1 Like
#8

@clementchdn

I recommend taking a look at @Alexander_Johannesen’s suggestion above.

-Sam

#9

Thank you @sam.rothstein. I replaced entities by primitives where I could and it helped.

#10

@clementchdn

I am happy to hear that :grinning: :rocket:

Please reach out if you have any more questions or comments.

-Sam

1 Like
Optimisation:Get height for many(150K+) points for draw primitives up to terraine
#11

Can i send question - you use only lon/lat coords or also use terrain provider & height data as 3rd coords?

#12

Hi @dihand, thanks for your question! Are you interested in any specific providers or data types?

#13

Hi @sam.rothstein , Thanks for the clarifying question - no, I was referring to the basic version of the terraneProvider.
In my exp, I seed that can be this is resource intensive operation. Of cources I understand, this pipline certainly optimized. But it can be funny to watch how, when the camera fly to near , an object that seems to be at the level of an ellipsoid disappears under the ground(after added heightmap from TerraineProvider to camera frustum), and then jumps to the height level (this is often seen when the height is automatically calculated, as sample Heightreferences = ClampToGround) - this is not a complaint - I write, just a note that such a flow also gives an additional load and for 1000 objects with a refresh rate of 10 Hz it can be noticeable as it seems to me

1 Like