Hardware or software?
Carsten
I have a working 3D modeller, .. or something that can show
position.normal.colored vertices on indexed draw calls. To make
something like that happen, one obviously has to have put some efford
into it. I think that I did, yet feel stupid on asking questions about
decisions that I've taken and that I havn't got the foggiest idea
about. One very early one is a parameter about something like using
software or hardware (I would be more specific, but it's on another
computer, I'm sure you know what I talk about). I've chosen the
'software' parameter, I think that I tried the 'hardware', without
success, but on my part, it's blind fighting anyway.
My pc are using a Radeon graphics-card, a couple of thads better than
the in-build graphics hardware - which of them, if any, is engaged
through my coding?
I can get a lot of information about the performance or different
graphic potentials (which shaderversion, max number of vertices and so
on). I hardly use any of it, but the question still is, whics graphics
hardware it's reading. I think I recall a max limit of 6mill
vertices ... my 300*300 grid is plenty to exhaust resources and create
delays, but that's a minor issue right now, as is which card. But with
all those potentials ... what is the 'software' parameter refering to
or would there be any notizable change in coding if 'hardware' were
used.
Another more nagging question.
The last couple of days, I've been working on one of those issues that
throws an illigal memory access/write (or something) - and restarts
the pc. I think that I've narrowed it down - having the pc shut down
like that is the reason why I'm afraid to approach a more dynamic
way ... like altering the vertex or index-buffer in response to user-
input. Currently I write one large buffer, and stick to altering draw-
commands. I can pick and aggregate a lot of different simple pre-
generated models - but I want a more free approach, by taking in
mouseclicks and build. I think that I recall, that I add a parameter
to the buffer I use (would that be in swapchain-discard?), where I
could use 'dynamic' instead. What sort of precaution can I take, to
minimize those fatal errors? The last days, I've seen a restart even
though cushing a draw-call in a try/catch. The form that 'does the
work' is written in C# (writing buffers internally, when called from
my external VB code). The doobious functions in C# is marked by
'unsafe/' (for the compiler, right?). When I compile my code, I get a
warning that's something like 'commandline parameters will not be
allowed'. I fear, that it refers to the 'unsafe/' keyword I use.
When I tap through my code, debugging, I think of all the violations
I've made when the debugging .. withers away with a 'no resourse
available' .. while setting something as innocent as 'Initial
directory' and 'Filter'-parameters for a simple save-file-dialog. I
can live with a re-install. What's the chances for doing permanent
damage?
I'm sorry for making so long posts, but I've been on my own from the
outset of this 3D thing.
Carsten
Note
On my latest error .. I've checked and checked. I make no mistake. I
render two identical objects, one has been written and read back from
file. (they are generated by the same geometry-function, and after
filing, both vertice- and indices-values are checked to be identical)
It starts out flawless, while camera looking away - but when it's in
the frustrum, it's either rendered lousy, close-down the pc or lets
itself get cought in the try/catch .. apparently depending on, how
fast I move the mouse ;o/
It's because I use VB, right?
And, for a smile.
The vertex index of the vertex-buffer ends up as a value in the index-
buffer. That doesn't make an index of an index buffer a vertex index,
but it is an index buffers index to where a vertex index is
.. right?