I don’t want to be bad but before to move to other api or upgrade 3d models engine or similar, why don’t improve the features that , now, are bottlenacked of XP?
I prefer to have 10 or more cloud layers, seasonals textures,weather injector that works well and permit to flight into a cloud system and not pass from sun to rain in a bit, theese are the elements the feel XP closely to real.
I believe that should be fix all the actual features, XP has big potentiality but the time run in april will be delivery the new FSX with 64 bit architecture and totaly rewrite in the code with new 3d Engine, i’d lite to see XP as leader on market and not other sim

I’ll try to blog more about it at some point in the future.

Thanks for filing the bugs. I fear that what you may need to change your work-flow. Basically you want to never try to get precise alignment at a long arm from an OBJ.

It’s really interesting to see what stuff you are cheking out for x-plane future!

A while ago you talked about Physically Based Rendering , could you please elaborate more about it in another post?

Hi Ben, I have just finished filing 3 bug reports:

1. I just realized that TEXTURE_NOWRAP isn’t working with any OBJs at all; no matter if they’re draped or undraped. It just returns a solid gray model.

2. Registration of OBJ centers/origins with POLs is indeed very precise, but the precision decreases with distance from the origin. Even at 300m away, the inaccuracy is enough to potentially require trial-and-error placement in WED for objects that must align to each other. At 3,350m away, the inaccuracy is just massive. It seems that OBJs are uniformly scaled down towards the origin in X-Plane–check the bug report.

3. The third bug report was for the OBJ8 specification not containing the commands relevant to a separate texture for draped geometry, e.g., TEXTURE_DRAPED.

I’ll try to reply to the bug filed soon…the short:
1. TEXTURE_NOWRAP should work as your draped texture; file a bug if it doesn’t.
2. Registration of OBJ centers with polygons should be very precise. If it isn’t, I’d like a bug report. I recommend using wind socks as ‘pins’ to test the registration of any given point and the four corners. When doing this, make sure the airport height listed matches the DSF terrain you are overlaying for correct results.

Hi ben,

Thanks for the reply. Before I file a bug, could you confirm that this is indeed a typo? The OBJ8 spec at http://developer.x-plane.com/?article=obj8-file-format-specification says: “OBJs support all of the standard shader features, for use in the draped texture: TEXTURE, TEXTURE_NOWRAP, TEXTURE_LIT, …”. However, it doesn’t tell us how to invoke these commands for the draped texture.

I found out from a post on X-Plane.org that the command to invoke a basic texture for draped geometry is TEXTURE_DRAPED, but couldn’t find anything on how to invoke a nowrap texture for it. So I guessed commands like TEXTURE_NOWRAP_DRAPED and TEXTURE_DRAPED_NOWRAP but nothing worked. Does a command for using a nowrap texture with draped OBJ geometry actually exist?

RE: Draped geometry being cut off: Yes, the OBJ contains only a draped orthoimagery tile (4 vertices). I tried manually inserting the OBJ into the other tile (+32-097) but DSFTool throws me:

ERROR: could not place object -97.048995, 32.887478
ERROR: !”ERROR: could not place object.\n”
(..\..\src\DSF\DSFLibWrite.cpp, 1449.)

I guess I’m placing it too-out-of-bounds?

The reason I’m not using POLs is to avoid this: http://gatewaybugs.x-plane.com/browse/WED-525
By creating everything in Blender and then simply placing it at a single origin in WED, I can rest assured that everything is perfectly aligned in X-Plane and I do not have to use trial and error to align OBJs with POLs.

that worries me

you guys need to think long and hard about not dropping Apple
i get thats what you guys like but Apple REALLY IS holding the sim back do to both hardware and software choices

Apple really isnt in the consumer performance market any more sure the Mac Pro kinda can keep up but all the consumer level stuff is running on laptop hardware

and i have not heard good things about Metal most its missing things that both DX12 and Vulkan have

considering that Apple users can easily install Linux or Windows seems silly to keep spending time and money OS X for what ever comes next

Frontier had to make the same call with Elite and Apple has made it clear to Occulus that they dont really care about high end consumer computing

the guys that did Talos Principle are saying its pretty trivial to add it

http://www.anandtech.com/show/10047/quick-look-vulkan-performance-on-the-talos-principle

they got it working in about a week or so on a DX11 game….

Frontier had an issue where they needed Compute Shaders for Elite which the current ver of OGL on OS X does not support (amusingly if they would just move up 1 point release it wouldnt be an issue)