• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Paul C Skertich

If there's more indices loaded - does the shader need to have more bytes?

20 posts in this topic

I noticed, I can import my custom mesh of a box, or a cross and zero problems. However, if I import a custom mesh using more than 2000 indices or around the 1000 range. The mesh won't show up. Currently, the shader's bytewidth is set at 178. Would I have to adjust this?

Thanks for awesome input!
0

Share this post


Link to post
Share on other sites
[quote name='SIC Games' timestamp='1344497601' post='4967658']Currently, the shader's bytewidth is set at 178. Would I have to adjust this?[/quote]Can you clarify what you mean here. What is the bytewidth of a shader?
Do you mean the size of your vertex/index buffers?
0

Share this post


Link to post
Share on other sites
Sure, the Constant Buffer that has the input element layout for the shader. In the Buffer Description for the Constant Buffer. The ByteWidth is set 178. I looked up on MSDN and it shows that in the Buffer Description that a ByteWidth represents width of bytes returned.
0

Share this post


Link to post
Share on other sites
So, the question would still remain that if I can load a simple cube or a simple box....then I should've have a issue importing a heart model than - correct? I created a model valentines heart in Zbrush4 then in Max I converted into OBJ - Triangles. Converted into my custom format with the conversion application...finally, it doesn't show up but a blue screen which just indictates that DX is initialized. The cross and the Cube were made in 3D Studio max and converted and they work.

So, regarless the mesh should load property right?
0

Share this post


Link to post
Share on other sites
It depends on your code whether it is able to load or not. DirectX has no problems with that as long as you tell it what to load and what it is.

Edit:
Maybe you'd like to show how you load that heart model? Edited by Ripiz
2

Share this post


Link to post
Share on other sites
Yes, this sounds more like a problem with your obj-loading code. The bytewidth you should be changing is the one of your vertex and index buffers, not your constant buffer. Edited by powly k
1

Share this post


Link to post
Share on other sites
Made a quick video of what's going on. I show in this video comparison of the demo cross loaded fully and just a simple cone import which failed. I

[url="http://www.youtube.com/watch?v=2flX9yNlzoc&feature=youtu.be"]http://www.youtube.com/watch?v=2flX9yNlzoc&feature=youtu.be[/url]
-2

Share this post


Link to post
Share on other sites
The part of code you showed is fine.

But we need to see how you load your .sgm files, or more specifically, code that creates vertex and index buffers for the model. Edited by Ripiz
0

Share this post


Link to post
Share on other sites
So, I get a minus rep point because I showed what the world I was talking about? Dat's messed up. As you can see in the freaking video the GD Cross loads. Nothing wrong with the Custom Mesh importer. It just doesn't like Hearts and cones. FIne, I'll look over the code AGAIN and see what I can come up with. Wow, showing a video - minus rep point! F'ing gay! Ripits said how about show what's happening. So, I did.
-1

Share this post


Link to post
Share on other sites
It wasn't me who downvoted, video is way too long just to show that it's not loading, not to mention you already told that in the first post. Fact that it doesn't load doesn't help to solve it, we need error messages or at least some code.

Your operating system looks like Windows Vista either Windows 7, you could use PIX from DirectX SDK to analyse whether your buffers were created, see how mesh looks like before and after vertex shader, etc.
0

Share this post


Link to post
Share on other sites
Loads index's and Vertex's
Namespace ModelManger - Class Model. Native Class code MESH. Native Class just has declarations for VertexCount and Indices.

This is part of the Loading Custom Mesh.
[code]
D3D11_BUFFER_DESC indexBufferDesc;
ZeroMemory( &indexBufferDesc, sizeof(indexBufferDesc) );

indexBufferDesc.Usage = D3D11_USAGE_DEFAULT;
indexBufferDesc.ByteWidth = sizeof(unsigned long) * MESH->IndexCount;
indexBufferDesc.BindFlags = D3D11_BIND_INDEX_BUFFER;
indexBufferDesc.CPUAccessFlags = 0;
indexBufferDesc.MiscFlags = 0;

D3D11_SUBRESOURCE_DATA iinitData;

iinitData.pSysMem = indices;
dev->CreateBuffer(&indexBufferDesc, &iinitData, &pIBuffer);

devcon->IASetIndexBuffer( pIBuffer, DXGI_FORMAT_R32_UINT, 0);


D3D11_BUFFER_DESC vertexBufferDesc;
ZeroMemory( &vertexBufferDesc, sizeof(vertexBufferDesc) );

vertexBufferDesc.Usage = D3D11_USAGE_DEFAULT;
vertexBufferDesc.ByteWidth = sizeof(Mesh::VERTEX) * MESH->VertexCount;
vertexBufferDesc.BindFlags = D3D11_BIND_VERTEX_BUFFER;
vertexBufferDesc.CPUAccessFlags = 0;
vertexBufferDesc.MiscFlags = 0;
D3D11_SUBRESOURCE_DATA vertexBufferData;

ZeroMemory( &vertexBufferData, sizeof(vertexBufferData) );
vertexBufferData.pSysMem = OBJVertices;
HR( dev->CreateBuffer( &vertexBufferDesc, &vertexBufferData, &pVBuffer));



D3DX11CreateShaderResourceViewFromFile(dev, // the Direct3D device
L"Wood.png", // load Wood.png in the local folder
NULL, // no additional information
NULL, // no multithreading
&pTexture, // address of the shader-resource-view
NULL); // no multithreading



[/code]
this loads the SGM file and sorts through everything. Making sure it's X,Y,Z, Normals, and U, Vs.
[code]
bool result;



char input;

char input2;

ifstream fin;

MESH->VertexCount = 0;
MESH->IndexCount = 0;

// VertexIndex *verIndex;

unsigned long * indices;



fin.open(filename);
if(fin.fail() == true) {
return false;

}

fin.get(input);

while(input != ':') {
fin.get(input);

}

fin >> MESH->VertexCount;

MESH->IndexCount = MESH->VertexCount;

indices = new unsigned long[MESH->IndexCount];




Mesh::VERTEX *OBJVertices;
OBJVertices = new Mesh::VERTEX[MESH->VertexCount];

fin.get(input);
while(input != ':') {
fin.get(input);

}

fin.get(input);
fin.get(input);

for(int i = 0; i<MESH->VertexCount; i++) {
int normx, normy, normz;

fin >> OBJVertices[i].x >> OBJVertices[i].y >> OBJVertices[i].z >> normx >> normy >> normz >> OBJVertices[i].U >> OBJVertices[i].V;
OBJVertices[i].Normal = D3DXVECTOR3(normx,normy,normz);

indices[i] = i;

}



fin.close();
[/code]

INside the converter the program loads the OBJ values and when converting sorts them out through their indices. So, there's no need to worry about figuring out the indices. This is where the Indices[i] come into play because there's no Indices to worry about. Additionally, when converted the SGM model format is already indexed flipped and minutes Z's for texture coord, normals, and vertices.

This is the draw call inside the engine.

[code]

void Draw() {

cBuffer.LightVector = D3DXVECTOR4(1.0f, 4.0f, -2.0f,0.0f);
cBuffer.LightColor = D3DXCOLOR(0.5f, 0.5f, 0.5f, 1.0f);
cBuffer.AmbientColor = D3DXCOLOR(0.2f, 0.2f, 0.2f, 1.0f);


// select which vertex buffer to display
UINT stride = sizeof(Mesh::VERTEX);
UINT offset = 0;
devcon->IASetVertexBuffers(0, 1, &pVBuffer, &stride, &offset);
devcon->IASetIndexBuffer(pIBuffer, DXGI_FORMAT_R32_UINT, 0);
// select which primtive type we are using
devcon->IASetPrimitiveTopology(D3D11_PRIMITIVE_TOPOLOGY_TRIANGLELIST);
// draw the Hypercraft
devcon->UpdateSubresource(pCBuffer, 0, 0, &cBuffer, 0, 0);
devcon->PSSetShaderResources(0, 1, &pTexture);
devcon->DrawIndexed(MESH->VertexCount, 0, 0);
}

[/code]

This function updates the matrixes.

[code]
void update_Matrixes() {
//--- Let's see if we need to move camera anywehere important.
MESH->worldMatrix = MESH->rotation_Matrix * MESH->translation_Matrix;
cBuffer.final = MESH->worldMatrix * viewMatrix * projectionMatrix;
cBuffer.Rotation = MESH->rotation_Matrix;
}


[/code]

The position and rotations are both set in the editor.

I didn't mean to get all hasty but minus a point for trying to show a video on what I'm talking about. Just doesn't make sense.
0

Share this post


Link to post
Share on other sites
I can't see any mistake there. Are you sure your mesh isn't simply too small or too big to see it?
As I mentioned in the last reply, you could try to use PIX to see if GPU has correct data to work with.
1

Share this post


Link to post
Share on other sites
I thought about it being too big or too small - so it's good to hear that as well. I'm checking into it now and will report shortly. Thanks Ripiz and everyone.
0

Share this post


Link to post
Share on other sites
I just checked video again, Cross and Cone coordinates aren't much different, they should be about same size.

At this point I'd say PIX is the only your chance (unless I missed something).
1

Share this post


Link to post
Share on other sites
Some general debugging advice:
* Every D3D function that returns a HRESULT expects you to capture that return value and check for success. There's a lot of missing error checking in your code, where if something is going wrong, you'll continue on anyway and silently ignore the error.
* Whenever something unknown/weird is happening in D3D, change your device creation code to add in the debug-device flag -- this will print out error messages if you're doing anything suss with the API.
* If the above don't catch an error, then launch PIX and use it to capture a frame from your game. You can then inspect what's happening during the offending draw-call, such as whether there's actually any vertices in your vertex buffer, or if pixels are being rejected by back-face culling, etc...
2

Share this post


Link to post
Share on other sites
I tried to use PIX and it said Failure Creation Progress. What I did notice is that in the drawing topology when I chose to use TriangleStrip it would draw it but a stretched out triangle effect would happen. If I did TriangleList_Adj it would draw the cap part - believe of the cone. At least it's something but I'll investigate further. As of now I'm trying to get PIX working and seeing why it's saying Failure Creating Process.
0

Share this post


Link to post
Share on other sites
Inside where it gathers the SGM values - I temporary stored the Normals X Y Z as a Integer! ROFL! Talk about up all night programming tireness. Now it draws a sphere! Additionally, Ripiz I have to move the camera back some to actually see it! :) Thanks everyone!
1

Share this post


Link to post
Share on other sites
Big Thanks to everyone that chipped in! Plus big thanks for me to see that normals can't be INT.s Here's a screen shot of a successful Sphere Import.

[attachment=10595:Sphere-CustomMeshModel.PNG]
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0