No ID3DX10Line?
I do not see any documentation for a D3D 10 version of ID3DXLine. Granted the DX9 ID3DXLine interface is a complete joke -- both in performance and quality, at least there is a way to get a few stylized lines in the 3D view. While games don't use stylized wireframe, this is a cornerstone for profession graphics packages (e.g., modelling and drafting). Current hardware supports accurately rendered, deterministic zbuffered, accelerated lines with widths up to 5 pixels wide. Common screen space dash patterns are sufficient for 90% of all display purposes. There are also several hidden line algorithms that only function correctly if the wide lines are rendered with correctly depth buffered Bressenham step patterns. Until Direct3D provides access to the full functionality of the current underlying hardware, it will continue to be viewed by professional graphics application developers as a second rate API. There are certain aspects of true wide line graphics that cannot be correctly represented by polygons, quads, or triangles.
[1046 byte] By [
tranders] at [2008-2-13]
It’s still controversial how much of these wide line are really implemented in the hardware and how much is done by drivers. But as you say games don’t have much use for wide lines. I couldn’t see that CAD software would be upgraded soon to Direct3D 10.As long as OpenGL or Direct3D 9 offers anything they need there is no reason to go with Direct3D 10 as it would make their software unusable on nearly every system. You said that the D3D9 implementation of lines is slow and have a bad quality. This would not be different with a D3D10 counterpart as the core API and the driver interface simply doesn’t include native support for wide lines. You can say that this is a big mistake but it seems that the people that have reviewed the drafts long before the public gets a first preview last December doesn’t though the same way. Maybe the reason was limited hardware support because anything that could not support native be the hardware should not be part of the core D3D10 API as one of the main aims was to reduce driver overhead.
Acceleration of wide lines is easy to confirm. I have an application that displays a single wiremesh teapot and there is absolutely NO drop in performance with wide lines in OpenGL. In Direct3D, there is about a 60% drop in performance for the same test using ID3DXLine -- mostly because there is no VB or mesh support through that API. That was just one simple teapot and the drop is much more significant for larger models (e.g., 20x slower). The hardware is absolutely accelerating the wide lines in OpenGL and also accelerates other glaringly missing aspects of D3D's fixed function rendering (e.g., two-sided lighting, two-sided materials, etc.). I am not advocating the use of ID3DXLine but it just looks like D3D10 is dropping this altogether so an application that eventually DOES move to D3D10 is just out of luck. The problem is not that CAD applications will quickly switch to D3D10, it's that D3D (any version) is simply a sub-par API for precision graphics. It is not the Microsoft is not aware of these requirements from CAD application developers, so there is really no excuse for continuing to keep these hardware accelerated features away from the D3D developer.
Don’t get me wrong. I didn’t say that it is not hardware accelerated at all. I am just saying that we don’t now how much work the driver need to do in advanced to finally let the GPU do the job.
A speed comparison between OpenGL and ID3DXLine may be interesting but didn’t say much anyway because it seems that ID3DXLine was never build for rendering large meshs. An optimized version that can cache already done work should provide better performance but as long as not enough people request such features it will not happen.
Considering that most of the current functionality of Direct3D is derivative work that was first implemented or provided by OpenGL, and considering that the hardware (and its associated low-level driver -- below the OpenGL API) already support accelerated wide lines, the amount of effort is relatively trivial.
The speed comparison is very important because it shows that the hardware is capable but the API is not. The problem with ID3DXLine goes beyond the ability to cache the the "results" of previous computations, the problem is that the algorithm is (i.e., converting wide lines to long, skinny quads/triangles) is intrinsically flawed with respect to generating precision output in the depth buffer. If you do not understand that difference, then you are probably not concerned with wide lines anyway. My hope is that Microsoft reads this forum and starts to connect the dots between "wanting applications to port from OpenGL to D3D" and "providing equivalent replacements for existing functionality".
There are people from Microsoft that read this forum but this would not bring you wide line support for Direct3D 10. It’s to late for such changes on the core APIs and even more for the driver interface. But anyway I still believe that wide lines are not fully implemented in hardware and therefore don’t match the requirements for Direct3D 10.
You can get correct depth values with small triangles as long as you have an exact definition how to calculate all necessary vertices.
The speed difference shows nothing at all. Compare the number of draw calls you can do with D3D and OpenGL per second on a Windows XP system. You will see that an good OpenGL driver outperform D3D easily because of the high overhead of the D3D driver interface. In the case of ID3DXLine vs. the OpenGL wide line function it is even worse as we compare something that is a universal extension over an API against a maybe highly optimized driver method.
Anyway all I can say is that you want to see anything in a Direct3D version you have to tell this Microsoft very early. As there is hardware involved we have to life with long latencies.
The addition of wide line support would not impact the API at all. Adding a capability bit (and associated value) does not break any COM rules and the desire to NOT support this by Microsoft is purely arbitrary. Driver support for an additional enumeration allowing control of wide lines would definitely be a driver issue, but again the implementation is relatively trivial and would have little impact on the current D3D9.?/D3D10.? interface.
Getting correct depth values using small triangles would require the application to know the precise stepping of the Bressenham algorithm for the long sides of the triangle. Wide line stepping in OpenGL is always aligned but the Bressenham of opposing long edges of the two quads are almost guaranteed to be misaligned. This is not something the application can determine consistently and definitely not efficiently.
The speed difference shows that the graphics card/driver support wide lines at a very low level. Granted the ID3DXLine interface is built on top of an API and layering is one of the main problems. My original complaint is that even with the poor support for wide lines in D3D9, there is absolutely NO support for wide lines in D3D10. These are the exact issues that Microsoft must address if they ever want to convince professional applications to switch to D3D.
I guess PDC 2003 wasn't early enough.
One of the main rules for Direct3D 10 is “No more Caps” therefore they could only add features that any IHV is willing to provide. But even if any vendor agree it would require changes on the driver interfaces (D3D9 and D3D10 have different interfaces; not COM based). I am not sure if this is true for D3D10 but the WDK is already sealed for WHQL.
D3DX10 is still a moving target therefore if there are enough people that want a ID3DX10Line there is a chance that it will add. Unfortunately I have the felling that currently not many people have take a look at D3D10.
PDC 2003 should be early enough but it seems that there were not many followers.
No caps is fine by me. Simply don't honor the request if you don't support the requested function -- that's no different than it has always been. DirectX 3 drivers used to blindly respond that they supported antialiased wireframe and simply did not draw ANYTHING. I don't care if low end cards don't do what I ask, but I DO care if high-end cards don't. If an API doesn't have some level of fallback behaviour then the entire API will be limited by the least common denominator. Considering that ICD accelerated OpenGL is still a viable API on Vista, it will be sometime before the graphics cards "dumb down" to the level of the D3D API.
I'm not sure why you say that D3D9 and D3D10 interfaces are not COM based. They are all based on IUnknown and are deleted when the final call to Release is made. They may not be registered with CoCreateInstance, but that doesn't mean they are not COM based. Anything beneath the upper level API is easy to change -- if you know what you're doing.
By pure numbers alone, the professional CAD market is probably less than 10% of the entire desktop market and the OpenGL portion of that market may even be less than that. Market share does not always indicate the importance of a particular feature.
You are trying to generate a support nightmare?It may be acceptable for you that cards ignore requests to draw something but such things can’t be accepted for the wide mass of developers. Do you want to be the guy on the telephone line that tries to calm down the angry customers?
You are right that Direct3D 10 will only support the least common denominator. This may be a problem for some use cases but if you ever have written game software you would be more than happy with a least common denominator on a high level. At the moment as developers we have to handle many different special cases, which is a nightmare, as you need additional effect paths to handle it.
I was talking about the interface between the Direct3D runtime and the driver. These interfaces are not COM based. They mainly use arrays with function pointers and handles. Most people don’t need to care about this as the runtime do all the dirty work.
As this interface is a contract for the driver changes there will have at least as much impact as on the API side of the runtime. Normally even more because not every application uses every aspect of an API but a driver have to implement the driver interface completely. I am not sure if you have ever work on drivers or these parts of an operating system. If you have you should understand the impact that changed could have there.
Btw: you should not believe that DirectX objects are always destroyed after the “final” release call. Even if it return 0 the object can still exist.
I've being developing CAD software for 20 years. Support is a two-edged sword -- if you tell the customer up front that the software requires a specific type of graphics cards with a specific level of functionality, the customer becomes the responsible party. Most graphics card vendors will not support CAD applications on consumer level cards anyway. My support "nightmare" is when I have a customer that spends $2000 US on a high-end graphics card and the "next generation" API is incapable of providing access to functionality that is absolutely accelerated by that card. Not withstanding the poor quality and performance of DX9's ID3DXLine interface, one would expect that newer API's would not DROP functionality -- rather you would expect the API to add functionality or improve performance of existing functionality.
Relative to the interface between the D3D interface and the driver, the tabular approach is no more difficult to enhance than anything else and still not impact the API or the myriad of drivers already in the field. I worked with the people that developed the very first OpenGL accelerated driver for Windows NT so I know what it takes. OpenGL ICDs have had to implement the entire OpenGL spec -- even if they did not accelerate all functions of the spec. Granted, it is not always easy to determine which parts are accelerated and which are not -- but at least everything "worked". IMO, if a company is designing a "next generation" API and uses a fixed set of tables for functions and handles to communicate with a driver but does not provide for the possibility of expanding or enhancing that set without significant impact, then that company is developing software that is very short sighted.
With respect to your statement on releasing an interface -- if I create an object and know its lifetime and all the ways that the interface may have been AddRef'ed by other interfaces, that object had better go away when I release it the final time -- otherwise I would consider that a memory leak. I deal with models in excess of 3GB so deterministic control over memory, resources, and performance are critical.
I'll stop beating this horse -- I just think that dropping functionality is myopic.
I also develop CAD software (though not nearly as long as tranders has). I just want to add my two cents here and say that tranders is correct. Before we started writing our software, we evaluated OpenGL and DirectX. I quickly discovered what tranders is complaining about. ID3DXLine interface was the only way to draw accurate 3D, variable width lines in DirectX. I ran similar tests to tranders and found similar results. Using the ID3DXLine interface is a performance nightmare. OpenGL, on the other hand, does not suffer this bottleneck.
We ended up going with OpenGL for a couple of reasons, but by far the most important reason is variable width line support. The hope was that DirectX would come around in some future version, and include good support for this necessary functionality for CAD developers. I have not read the DirectX 10 specification yet, but I will say that removing ID3DXLine with no other replacement is a step in the wrong direction. I agree with tranders' argument that adding this support to DirectX should be relatively trivial for Microsoft.
I understand the argument about how DirectX 10 is designed around only supporting those things that are supported in hardware. While game developers must love this (it makes it more like programming for a game console), CAD/CAM and scientific modeling will now have less of a reason to use DirectX. I understand that game developers are the majority of the users of DirectX, it just doesn't seem right that CAD developers should be ignored when all of what we are requesting should be relatively trivial to implement.
Just one last thing... I also have to agree with tranders on the COM interface releasing issue. If you call release enough times to get the internal reference count down to zero, that object better go away. That's part of the contract of resource management in COM and developers count on that when managing their resources. While it's true that Microsoft could have implemented these objects to not go away when the reference count reaches zero, this would definitely be considered bad COM design.
Seems to me that you're missing one key point with regards to dropping line support - its still a beta! (I'm sure I don't need to elaborate on what this means 
)
Do a quick comparison between the D3DX10 and D3DX9 functionality - notice that D3DX10 is still very light by comparison. I was asking about this last week - there are some functions I want to be using on meshes that I have to go back to D3DX9 to get (I have a v9->v10 conversion function I wrote). Bottom line - the core runtime is a system level component and is tied to the launch of Vista; D3DX is a convenience tool for developers and is not tied to the OS at all. Given what is publicly known about the Vista launch schedule it shouldn't be too surprising that they're getting the core API sorted before they go on to the optional parts...
There are at least two SDK's before Vista ships and I'm expecting to see D3DX10 pick up before it goes final - I don't know, but maybe you'll get ID3DX10Line soon 
Also, have you considered looking at line extrusion on the GPU? I'd imagine there is some scope for doing interesting things via the GS. Just because you're used to the OpenGL way of doing things doesn't mean you have to try and emulate it in exactly the same way in a different API. The rasterization and precision rules for D3D10 are much more strictly defined than D3D9 which may also work in your favour going forwards.
hth
Jack
 Jonathan_DeCarlo wrote: |
| I also develop CAD software (though not nearly as long as tranders has). I just want to add my two cents here and say that tranders is correct. Before we started writing our software, we evaluated OpenGL and DirectX. I quickly discovered what tranders is complaining about. ID3DXLine interface was the only way to draw accurate 3D, variable width lines in DirectX. I ran similar tests to tranders and found similar results. Using the ID3DXLine interface is a performance nightmare. OpenGL, on the other hand, does not suffer this bottleneck. We ended up going with OpenGL for a couple of reasons, but by far the most important reason is variable width line support. The hope was that DirectX would come around in some future version, and include good support for this necessary functionality for CAD developers. I have not read the DirectX 10 specification yet, but I will say that removing ID3DXLine with no other replacement is a step in the wrong direction. I agree with tranders' argument that adding this support to DirectX should be relatively trivial for Microsoft. I understand the argument about how DirectX 10 is designed around only supporting those things that are supported in hardware. While game developers must love this (it makes it more like programming for a game console), CAD/CAM and scientific modeling will now have less of a reason to use DirectX. I understand that game developers are the majority of the users of DirectX, it just doesn't seem right that CAD developers should be ignored when all of what we are requesting should be relatively trivial to implement. Just one last thing... I also have to agree with tranders on the COM interface releasing issue. If you call release enough times to get the internal reference count down to zero, that object better go away. That's part of the contract of resource management in COM and developers count on that when managing their resources. While it's true that Microsoft could have implemented these objects to not go away when the reference count reaches zero, this would definitely be considered bad COM design. |
|
It's good to know that I'm not just a lone voice crying in the wilderness.
How smart do you have to be to figure out that developers need line support in DirectX 10? Lets wait and see if DirectX 10 team gets it. If they don't they should get out and make room for others.
