20,741
edits
Talk:Switching default texture format to DDS: Difference between revisions
Jump to navigation
Jump to search
m
Talk:Switching default texture format to DDS (view source)
Revision as of 20:26, 15 September 2014
, 15 September 2014→Proposal for a change input format "on the fly" in the texture format
No edit summary |
|||
| Line 98: | Line 98: | ||
::::::::X-Plane already show all this animation and I'm always amazed how realistic it look, and I'm sure that this would be more appropriate for Canvas and SVG! | ::::::::X-Plane already show all this animation and I'm always amazed how realistic it look, and I'm sure that this would be more appropriate for Canvas and SVG! | ||
::::::::--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 20:12, 15 September 2014 (UTC) | ::::::::--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 20:12, 15 September 2014 (UTC) | ||
:: Have you meanwhile done any testing ? Frankly, this was just an idea because of a few postings on the forum. All testing that I've done on sufficiently modern hardware suggests that SVG/ShivaVG isn't currently a bottleneck. As you have probably seen, I've meanwhile experimented with this a bit and posted code to demonstrate how to do this kind of thing using Nasal/Canvas. | |||
:: Personally, I don't have any preference at all - but I also don't create liveries usually. And while shaders/effects are an obvious, and fast, method - not everybody has access to hardware that can run shaders. | |||
:: Typically, The people suggesting to use shaders/effects for such things are usually "power contributors" with a lot of GPU power. And as we can currently witness on the devel list, the effects/shader framework comes with its own issues and challenges, memory leaks and race conditions being pretty serious showstoppers obviously. Canvas has basically no barrier to entry and it allows people to do these kinds of things without having to learn effects/GLSL coding. | |||
:: It certainly cannot be compared to effects/shaders performance-wise, but that was never the point. Also, I am far from being opposed to shaders/effects - as you may have seen, we already started exploring effects/shader support to Canvas and expose Canvas textures to the effects system, which would allow people to do all kinds of fancy things without having to know much about C++ programming. | |||
:: Given that two contributors do have code doing this kind of thing, and given Zan's work, it is pretty likely that we'll eventually see this being merged. Whenever I've talked to aircraft developers about such features, they primarily want thing to work sufficiently fast, without any special-case treatments for things like Rembrandt - Canvas/SVG can provide just that. | |||
:: Overall, people will continue to use what works best for them - especially aircraft developers without a coding background will surely appreciate the simplicity of Nasal/Canvas here - all the things that you mentioned could be easily implemented in ~50-60 lines of Nasal code. But I am certainly not saying that we should discard effects/shaders, it's more about keeping hardware requirements in mind - and even if shader support is available, our scenery folks surely know how to make use of all the horsepower there... | |||
:: Also, there are various scenarios that could greatly benefit from run-time scenery modification in the sense that Canvas supports it - i.e. anything that is combat/damage related (think f14b or flug's bombable). Equally, the same method can be used for placing runway skid marks and so on. | |||
:: Conceptually, a Canvas property tree actually isn't much different from a SVG DOM - the main difference being that it is hardware-accelerated and using the verbose PropertyList XML format, but any Canvas can be expressed as a SVG tree and vice versa - thus, this kind of development is pretty natural.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:26, 15 September 2014 (UTC) | |||