Truform/NPatch's

C

chucks240

New member
Its is the NPatch's functionality of DirectX3D that
utilizes the 8500's Truform capability, right?

(dumb question...)

Just added a couple lines of code and a variable to the
Mesh Tutorial of DX8.1, along with a little work
converting a UT model to and .X file, and I was
able to get NPatchs to work. :p

Now I am just curious to see what kind of effect or
overhead it can cause even though this is a stationary
model. ;)

O.K. I know :rolleyes:, but hey its an accomplishment for me.
I had to tell somebody.

(My main problem is I am a perfectionist. So it takes me longer
to even like my own work.)
 
One note though...

One note though...

I do have to admint the models do need to be worked
on if they are simple. The Tiger mesh from the
tutorial didn't work well. The texture wouldn't cover all
of the primatives, triangles, or whatever you want to
call it when npatchs segments were applied with a value
greater than 1.

The more complex UT model worked great the first time.
:D
 
Well done, Chuck. If you have questions, we do have a good deal of sample code online, including a super simple N-Patch sample.

Now I am just curious to see what kind of effect or overhead it can cause even though this is a stationary model.
Click to expand...
The overhead of tessellation will be the same, regardless of how you animate the model. Running it through an identity transform is just as expensive as running it through any other kind of transform. Let us know when you get to skinning and such.

-Jason
 
Its a challenge..

Its a challenge..

As soon as I figure out the best way to convert the code that
is out there from OpenGL to DirectX3D I will start working
on that and other parts. Please note that my I haven't had
math, such a calc. for almost 13 years, and haven't really
touch C or C++ for about 5 years. I am a little rusty,
and I have very little time, but hey thats how we learn.

DX8.1 has a lot of capabilities, and for the most part
is more stable than OpenGL on my system.

All of the 3D model (UT/Q3/etc) viewers seem to be OGL based.

Any suggestions would be appretiated.

Thank you.

:D
 
Skinning question?

Skinning question?

O.K. rebuilt the (very simple) model viewer to view
3DS files instead of X (directx) files.

With N-Patches turned on, or 2 and above on segment values,
textures applied sometimes will have gaps. Like the texture
does not get applied to all of polygons. I even saw this with
the tiger mesh and texture in my original viewer.

Granted this is simple viewer. All I do is load the
vertex buffer will all of the verticies, normals,
and texture coordinates, and then I load a texture.
I added the Render States for D3DRS_PATCHSEGMENTS
and D3DRS_PATCHEDGESTYLE along with a variable to define the
number of segments. Thats pretty much it. I used
www.gametutorials.com OpenGL 3DS loading tutorial to get
the verticies for the model.

What else needs to be done in order to make sure the texture
gets applied to all of the patchs/segments/ or added
polygons?

Thank you,
Chuck
 
Only UT model I could come up with that had an available 3ds file
was the 6abbey model. As show here :
abbey_3ds.jpg

You can kind of see where the seems are not split.
Though the directx X file version :
abbey_x.jpg

Looks fine.
Though for the tiger mesh its just the opposite.
Here is the 3DS version :
tiger_3ds.jpg

and the X version :
tiger_x.jpg

/////////////////////////////////////////////////////////////////////
The X file version uses the DirectX X file functions.
While the 3DS was built seperately. All models have the
D3DRS_PATCHSEGMENTS and D3DRS_PATCHEDGESTYLE
rendering states set.


It is most likely what I am doing, and I am probably comparing
apples and lemons. I am just wonder what else I should be doing.
 
I'm not sure that what I'm seeing are texture errors rather than simply cracks. One difference in the two models/loaders might be the threshold angle used to determine a "crease edge." On the abbey model, it looks like the X file loader is fusing all creases and the 3DS file loader isn't. On the tiger, it looks like the opposite, which is odd. Can you turn on backface culling? If you do that, I'm betting you'll see blue (the clear color) through the cracks. That'll be an important datapoint. Can you zoom in closer on the flaws? You shouldn't have to touch the D3DRS_PATCHEDGESTYLE state. Just leave it at the default. Are you doing anything with the interpolation order states for normals or positions? Defaults should be fine on those...just curious.

-Jason
 
Turned on Culling and the blue does show through crack's.
Its a pretty simple viewer, so I do not do anything
fancy. The X file viewer is pretty much the DX81
mesh tutorial. The 3DS I built on my own, with a little
help. I noticied that the 3DS viewer is a little darker
than the X viewer, even though the X file was just a
convertion from the 3DS file, and the same texture file
is being used.

I will need to rewrite them to be a little more flexable.
 
Here is a zoomed and culled 3ds abbey model :

abbey_3ds_Zoom.jpg


Here is the dx tiger file :
tiger_x_Zoom.jpg



Ya know, I could have sworn I had this problem with the DX file version of the abbey model as well. At one point I did something,
and I do not know what, and the model started looking O.K.

I'll keep working on it.

I am getting a better picture of the convertion from OpenGL
to DirectX at least.
 
Should Normals be provided?

Should Normals be provided?

When using NPatches, is allowing DirectX to calculate the normals allowed, or should the normals be provided in the vertex buffer?
 
Re: Should Normals be provided?

Re: Should Normals be provided?

chucks240 said:
When using NPatches, is allowing DirectX to calculate the normals allowed, or should the normals be provided in the vertex buffer?
Click to expand...

Yeah, the normals should be in the vertex buffer.
 
Direct3D doesn't calculate normals. As an "immediate mode" API, Direct3D knows nothing of "models" or "objects" or anything like the topology of the geometry you're drawing. It's up to you to organize your data and provide all the necessary components of a vertex (such as normals). In the models above, there are clearly vertices which have the same positions, but not the same normals...this is what is causing the cracks.

-Jason
 
JasonM [ATI] said:
Direct3D doesn't calculate normals. As an "immediate mode" API, Direct3D knows nothing of "models" or "objects" or anything like the topology of the geometry you're drawing. It's up to you to organize your data and provide all the necessary components of a vertex (such as normals). In the models above, there are clearly vertices which have the same positions, but not the same normals...this is what is causing the cracks.

-Jason
Click to expand...

Perhaps the smooth angle is different on one...
 
Oops. Helps to read sometimes....

Oops. Helps to read sometimes....

Helps if I read huh, here(s) the little tid bit from the DXC++ Doc :
Generating Normals and Texture Coordinates
If you are using a flexible vertex format (FVF) shader, automatic
generation of normals and texture coordinates is not possible.

but it also say(s) :
For normals, you can either directly supply them to Direct3D or
have Direct3D calculate them for you. (so I think you can have D3D generate them)

But since I am using the FVF, I need to provide the normals
and texture coordinates.
 
Re: Truform/NPatch's

chucks240 said:
Its is the NPatch's functionality of DirectX3D that
utilizes the 8500's Truform capability, right?

(dumb question...)

Just added a couple lines of code and a variable to the
Mesh Tutorial of DX8.1, along with a little work
converting a UT model to and .X file, and I was
able to get NPatchs to work. :p

Now I am just curious to see what kind of effect or
overhead it can cause even though this is a stationary
model. ;)

O.K. I know :rolleyes:, but hey its an accomplishment for me.
I had to tell somebody.

(My main problem is I am a perfectionist. So it takes me longer
to even like my own work.)
Click to expand...

Hithere!! Believe it or not, I am even more in the dark than you are...but, I am working on my comp sci degree, and I have all the necessary software tools, just no clue as to how to get started in OGL programming...

Think you could provide a short explanation as to how you did the UT models, maybe a link to a tutorial or some such? (I have 3dsmax, a few UT plug-ins for models, and a brief background in C).

Also, if it isn't too much, know of any links to OpenGl programming tutorials?
 
If you're just starting out with OpenGL and have only a brief background in C, I would recommend starting out with the Red Book, which is one of the best technical books I've read/used on any topic, not just OpenGL. As for online forums, the OpenGL.org Beginners Forum is a good place to start. Of course, any ATI-related OpenGL questions you can ask right here at Rage3D.com and we'll do our best to help out.

-Jason
 
One more quick question: do I need to register as a developer at ATI's website in order to download the sdk and other materials?
 
Re: Re: Truform/NPatch's

Re: Re: Truform/NPatch's

hithere said:


Hithere!! Believe it or not, I am even more in the dark than you are...but, I am working on my comp sci degree, and I have all the necessary software tools, just no clue as to how to get started in OGL programming...

Think you could provide a short explanation as to how you did the UT models, maybe a link to a tutorial or some such? (I have 3dsmax, a few UT plug-ins for models, and a brief background in C).

Also, if it isn't too much, know of any links to OpenGl programming tutorials?
Click to expand...

You may want to read my first OpenGL tutorial: :)
http://hem.passagen.se/emiper/OpenGL/Tutorials/OpenGL_Basic_Framework/

I've put it up temporally on my current homepage until we can move our server down to university, so it'll be moved later on, hopefully within this week.

Anyway, I want some feedback on the tutorial (in case you want to read it) since I plan to up some more later on, targetting both newbie stuff and more advanced stuff.
 
You must log in or register to reply here.
Back
Top