Import/Export to/from blender issue

28 Jun 2020 20:47 #47372 by StuartC
Hang on, Take what on?
What did I miss?

Please Log in or Create an account to join the conversation.

28 Jun 2020 20:49 #47373 by Warty
A few posts back I offered to supply you with all my new .ac files

Mac 10.14.1 Mojave, FG 2018.3.5

Please Log in or Create an account to join the conversation.

28 Jun 2020 21:00 #47374 by StuartC
I had completely forgot about that, probably due to all the crap thats been going on ( real world ).
I do have your EC120 on the way though.



Attachments:

Please Log in or Create an account to join the conversation.

28 Jun 2020 21:22 #47375 by Warty
No problem, I'll potter along with the Gazelle animations. If you want, you can use it for FGUK when I'm done.

The EC120 is looking good and I presume you also got the paint kit for it. I found the most difficult part was the VEMD - particularly the torque calculations. Let me know if you need anything extra for it.

Mac 10.14.1 Mojave, FG 2018.3.5
The following user(s) said Thank You: StuartC

Please Log in or Create an account to join the conversation.

30 Jun 2020 16:30 #47392 by Warty
Some progress made but still many issue/glitches to resolve. Here is a demo/test/first-draft, whatever:

GitHub download

Liveries are random but if I change the names it will probably not work over MP. Similar for why the livery textures have been converted to the awful .jpg format




Mac 10.14.1 Mojave, FG 2018.3.5
The following user(s) said Thank You: StuartC

Please Log in or Create an account to join the conversation.

30 Jun 2020 18:15 #47393 by StuartC
Jpeg liveries are much smaller file wise and load faster over multiplayer. Can use png but it can cause longer loading times.

Please Log in or Create an account to join the conversation.

30 Jun 2020 20:44 #47394 by Warty
Just in case of confusion for anyone reading this in times to come: MP does NOT transmit the actual livery/graphics file to the other MP players. It simply transmits a location/file combo such as

Aircraft/Gazelle/Models/liveries/b-oobs.jpg

The receiving MP player's system will (if possible) load this file from its OWN system and apply it to its OWN current aircraft/fuselage model

The transmitter/receiver MP players do NOT have to have the same aircraft/fuselage models or the same livery/graphics files. So I can use this new version over MP and users of the older version will simply see the old model with the old livery.

The theory that smaller (.jpg) files load faster (over multiplayer or anywhere) is also debatable. One reason they are smaller is that they contain less information. For sure, your machine could transfer them to your graphics card faster but they are of no use as they are - they have to be decompressed. The graphics card needs them in a pixel-by-pixel format so it has to spend time creating this and ending up with an inferior product than if you had just sent it in .png format in the first place. Yes, .dds format graphics may be ideal but they are very difficult to work with.

Mac 10.14.1 Mojave, FG 2018.3.5

Please Log in or Create an account to join the conversation.

30 Jun 2020 21:05 #47396 by enrogue
With the newer FG, when you turn on the texture cache, they are converted into DDS, so all the mipmapping is done (but uncompressed unless you're on windows I think)

Please Log in or Create an account to join the conversation.

30 Jun 2020 21:20 #47398 by Warty
I'm not sure what the point would be of compressing a DDS file - but then Windows has always been mystery to me :unsure:

Mac 10.14.1 Mojave, FG 2018.3.5

Please Log in or Create an account to join the conversation.

30 Jun 2020 21:25 #47399 by Warty
"With the newer FG, when you turn on the texture cache, they are converted into DDS, so all the mipmapping is done"

Seems like a good idea, even less reason to use low-grade graphics.

Mac 10.14.1 Mojave, FG 2018.3.5

Please Log in or Create an account to join the conversation.

01 Jul 2020 09:57 #47401 by enrogue
The compression is the in card/vram texture compression formats - originally like S3TC. If OSG includes the nvtt (Nvidia Texture Tools) plugin then it is used

macos doesn't support it from memory (or dds texture very well tbh - only a limited set of formats), and in Linux it's dependant on the card/driver.

I've tested it with the nvtt plugin on Linux for AMD & Intel & while both work, they both have visual issues

The on disk texture cache makes a massive difference - I always have it on, but without texture compression

Please Log in or Create an account to join the conversation.

02 Jul 2020 11:56 #47405 by Richard
Using a higher resolution JPG (which has lossy compression) usually gives better rendering than a lower resolution PNG (which can often still be larger on disk). So I'd recommend a higher resolution JPG.

Secondly I've just realised that the DDS texture cache without compression may actually be a valid use case as it seems that DDS with compression (nvtt) is only working reliably on Windows.

The DDS texture cache is definitely worth leaving turned because it removes most of the frame pauses related to model loading; unless you are getting specific problems with it (please report all problems to the devlist or the main FG issue tracker)

Please Log in or Create an account to join the conversation.

Time to create page: 0.212 seconds
Powered by Kunena Forum

Latest Forum Posts

PM Notifications

You are not logged in.

PM Mailbox

You are not logged in.