Planet problems

Sorry if this suggestion is unrelated but could it have something todo with a death zone?
In my modification i have a planet that is 80000.sph the atmoshpere is around 81200 nd the death zone is around 80150.

im sorry if it doesnt help.

Just out of curiosity… If you’re going to make a planet texture as a cube map, why use a CMP planet at all? It’s less precise, LODs aren’t as good, wireframes are buggier, and you lose the atmosphere effect. Plus, it’s heavier.

The flickering is caused by the atmosphere. If you don’t care to have one, just make it entirely transparent and you’ll be set. Granted, planets look rather ugly without any sort of atmosphere, but it’s a tradeoff.

Also, bear in mind that CMP planets suffer from perhaps an even worse bug where polygons seem to flip inside out at a certain distance. Most of the time you can’t see that because models are too small, but with large planets it gets problematic.

However, 10-15k is not big. You likely wouldn’t have an issue with SPH planets even while using an atmosphere. Problems arose with planets 100-300k wide.

I am having the inside-out poly bug at 13k. If nothing else, I will put a 12k nebula around it lol.

There’s a hack for it if you’re willing to tweak:

20000f 	freelancer.exe 	1C8910 	FriendlyFire 	same offset as above, poly flipping distance - raising this value stops graphical glitches on big CMPs, but raising it too high introduces flickering issues with SPH-based models (like planets) 

Ah, thanks for that. I was afraid to mess with that one because it was tied to ships as well. I first tried 250k and regular planets flickered horribly. 60k is a nice medium, far enough not to notice the poly flipping and on the border of sph flickering.

edit, my planet is 4k radius btw, 8,000m diameter

I am cooking up something cool for Christmas

Aye, I meant that without changing the value from its default, you’d need some pretty darn big planets to have an issue. If you raise it, then the bug shows up rather quickly, which is a pain.

Yes, one of the first things we worked on was fixing planet atmospheres. I’ve also largely reconstructed them from scratch, as can easily be noticed if you compare vanilla ones with ours.

It’s part of the DirectX 9 client hook. “Sharing” it would involve sharing a few thousand lines of C++ code. It’s not exactly something you can do in isolation.

Hum…. I know you guys are genius on development bright code and software, but when FOW release so modders like me can use it to enhance their work by using FOW’s techniques? Time is short. Please.

BTW, FLHook is long without update.

FLHook has had plenty of updates on the Subversion repository. No, they don’t have neat version numbers and packages, but they’re what many servers use at the moment.

Be aware that those new versions require a partial rewrite of your plugins.

Ya, I hope we can release FLHook v2.0 soon, long overdue. Its currently a work in progress on the SVN and as FF said, we updated it quite a lot - especially the SDK with newly reversed stuff.

w0dk4 wrote:
Ya, I hope we can release FLHook v2.0 soon, long overdue. Its currently a work in progress on the SVN and as FF said, we updated it quite a lot - especially the SDK with newly reversed stuff.

And, wodka, please also pay some attention to compatibility.

Upgrade a mother software case incompatible is frustrating for me. You need check whose new sdk and so on to rebuild a new plugin.

And i think there some good plugins already under the status of unmaintainable, because of code lost, people afk and other reason.

I’ve never had to flip any texture for mapping onto SPH files, so I’m not sure what you mean by that.

Always DDS. TGA serves no purpose, especially for planets, which should always have square power of 2 textures.