Horde3D http://horde3d.org/forums/ |
|
Modifying vertices http://horde3d.org/forums/viewtopic.php?f=2&t=818 |
Page 1 of 1 |
Author: | marc9837 [ 17.06.2009, 20:11 ] |
Post subject: | Modifying vertices |
Hallo, i tried to manipulate the position of the vertices of a loaded resource. But Horde3D::updateResourceData(…) always returns FALSE and the rendered model isn’t changing. Is there a mistake in my code? Code: ...
float* _vertices; NodeHandle _node; ... void CompSoftBall::updateVertexPos( int index, float tx, float ty, float tz ) { ResHandle res = Horde3D::getNodeParami( _node, ModelNodeParams::GeometryRes ); int VertexCount = Horde3D::getResourceParami( res, GeometryResParams::VertexCount ); const float* Vertices = (const float*) Horde3D::getResourceData( res, GeometryResParams::VertexData ); if(!_vertices) { _vertices = new float[3*VertexCount]; for(int i=0; i<VertexCount; i++) { _vertices[3*index] = Vertices[3*index]; _vertices[3*index+1] = Vertices[3*index+1]; _vertices[3*index+2] = Vertices[3*index+2]; } } if(index<VertexCount) { _vertices[3*index] = tx; _vertices[3*index+1] = ty; _vertices[3*index+2] = tz; } if(!Horde3D::updateResourceData( res, GeometryResParams::VertexData, _vertices, VertexCount )) { cout<<"Error"<<endl; } } |
Author: | AcidFaucet [ 18.06.2009, 00:42 ] |
Post subject: | Re: Modifying vertices |
What are you expecting that 'for' loop to do? Index isn't changing and you aren't using i so you're setting the same three floats for every vertex. Is that what you want? Also, what has the debugger told you? Are you passing through all the code? What sections are/aren't being hit. Lastly, try switching over to vector temporarily, using a reserve the size of the vertex count of floats, and passing &YourVector.front(), YourVector.size() to the update resource function so you can peek inside the date more easily to see what's going down. So your for loop was probably intended to be something more like Code: vector<float> vertexData(vertexCount + 1 /*1 for saftey grace*/); for (size_t vertexSub = 0; vertexSub < vertexCount; ++vertexSub) { vertexData.push_back(vertices[i]); } /* OR */ vector<float> vertexData(vertexCount + 1 /*1 for saftey grace*/); vertexData.push_back(0.0f); //so we have a valid front memcpy(&vertexData.front(), vertices, vertexCount * sizeof(float)); if(!Horde3D::updateResourceData(res, GeoResPs::VertexData, &vertexData.front(), vertexData.size())) { //??? Do stuff here } /*Mileage may vary, I use my own STL, so you may not be able to do memcpy magic, though I couldn't see why not.*/ At least that what I'm thinking, though who knows what code is missing. |
Author: | swiftcoder [ 18.06.2009, 01:01 ] |
Post subject: | Re: Modifying vertices |
AcidFaucet wrote: Code: memcpy(&vertexData.front(), vertices, vertexCount * sizeof(float)); /*Mileage may vary, I use my own STL, so you may not be able to do memcpy magic, though I couldn't see why not.*/ It may work well enough for POD types, but if you apply it to a non-POD type (or a vector of non-POD types), it can (and often will) fail miserably: memcpy() is unaware of copy-constructors, for starters. For POD types std::copy() basically becomes memcpy(), so it will be equally efficient. |
Author: | marciano [ 18.06.2009, 01:09 ] |
Post subject: | Re: Modifying vertices |
The answer is much simpler (although a bit unsatisfying): Geometry resources are still read-only. But we plan to change this within the next days. |
Author: | AcidFaucet [ 18.06.2009, 03:57 ] |
Post subject: | Re: Modifying vertices |
Quote: The C++ equivalent of memcpy() is std::copy(). Never use memcpy() in C++. It may work well enough for POD types, but if you apply it to a non-POD type (or a vector of non-POD types), it can (and often will) fail miserably: memcpy() is unaware of copy-constructors, for starters. For POD types std::copy() basically becomes memcpy(), so it will be equally efficient. Ah ah ah, never said I don't use something similar to std::copy() where appropriate. It's outright stupid to do for floats. I wouldn't call 'unaware of copy-constructors' a bad thing. I'd be more inclined to call copy-constructors bad, the very reason for righting a NOCOPYDEF macro. Memcpy can't fail miserably unless you do something really silly with dlls, threads, or inter-process comm. If it can, I'd love to see a piece of code that will do it. |
Author: | swiftcoder [ 18.06.2009, 04:16 ] |
Post subject: | Re: Modifying vertices |
AcidFaucet wrote: Quote: The C++ equivalent of memcpy() is std::copy(). Never use memcpy() in C++. Ah ah ah, never said I don't use something similar to std::copy() where appropriate. It's outright stupid to do for floats. Quote: I wouldn't call 'unaware of copy-constructors' a bad thing. I'd be more inclined to call copy-constructors bad, the very reason for righting a NOCOPYDEF macro. Memcpy can't fail miserably unless you do something really silly with dlls, threads, or inter-process comm. If it can, I'd love to see a piece of code that will do it. Any class that manages resources is incompatible with memcpy(), because the copy-constructor and destructor won't be called. As a trivial example, you can't memcpy a boost::smart_ptr, or any std::library container:Code: std::vector< std::vector<int> > vec1, vec2;
vec1.resize( 100 ); vec2.resize( 100 ); memcpy( &vec2[0], &vec1[0], 100*sizeof(std::vector<int>) ); // mucho bad, because we just leaked several internal buffers, and will later double-free the rest |
Author: | AcidFaucet [ 18.06.2009, 06:10 ] |
Post subject: | Re: Modifying vertices |
Quote: As I said, std::copy() will behave identically to memcpy() Negative. Because of template specialization. Which is compiler/preprocessor dependent. Result, yes. Function, depends on definition. Furthermore, copying is bad. Copying should always be a work around for communication. Duplication, is waste. You don't copy strings when collecting data for a report, you collect pointers to objects that implement an "IGetString" interface. Your example is ..... I don't have a word. It's requiring you to do something which just screams "NO". Of course that's going to explode, it couldn't do anything else. Doing that is as bad as: Code: //dumbest code on planet
CRect bogus; if (bogus.IntersectRect(bobArea, myArea)) { //??? stuff } /*instead of */ if (CRect().IntersectRect(bobArea, myArea)) { //??? stuff } |
Author: | swiftcoder [ 18.06.2009, 13:15 ] |
Post subject: | Re: Modifying vertices |
AcidFaucet wrote: Quote: As I said, std::copy() will behave identically to memcpy() Negative. Because of template specialization. Which is compiler/preprocessor dependent. Result, yes. Function, depends on definition. Quote: Furthermore, copying is bad. Copying should always be a work around for communication. Duplication, is waste. You don't copy strings when collecting data for a report, you collect pointers to objects that implement an "IGetString" interface. No argument there - copying should be avoided - but when you have to, use std::copy().Quote: Your example is ..... I don't have a word. It's requiring you to do something which just screams "NO". Of course that's going to explode, it couldn't do anything else. Sure, but it was just an example to show how memcpy doesn't understand C++. If you use std::copy instead, that code sample works fine.
|
Author: | AcidFaucet [ 19.06.2009, 21:00 ] |
Post subject: | Re: Modifying vertices |
Quote: Try it - compile your code with std::copy and memcpy, and compare the generated assembly (in an optimised build)... Did it. Optimize for size, they're identical. Optimize for "speed", there's some extra junk to get to the actual copy, but that isn't the copy's fault.
|
Author: | SpOOky [ 24.06.2009, 17:30 ] |
Post subject: | Re: Modifying vertices |
marciano wrote: The answer is much simpler (although a bit unsatisfying): Geometry resources are still read-only. But we plan to change this within the next days. Have you managed to make the resources write-enabled? |
Author: | marciano [ 26.06.2009, 23:22 ] |
Post subject: | Re: Modifying vertices |
It is possible now to map textures for reading and writing, including individual mipmaps and cubemap faces. We also got a more powerful texture creation API which brings Horde's support for dynamic textures into good shape. Better dynamic geometry support is the next thing to be done. |
Author: | marc9837 [ 27.06.2009, 00:55 ] |
Post subject: | Re: Modifying vertices |
sounds good, because i created some soft-bodies with the bullet physics engine and render it with horde. at the moment i use some small spheres to render the positions of the vertices but it looks like a scale armor |
Author: | marciano [ 26.07.2009, 11:09 ] |
Post subject: | Re: Modifying vertices |
Read and write access to all geometry vertex attributes is possible now. There are still several things that can be optimized, for example to reduce memory footprint, but at least the basic functionality is available now. |
Page 1 of 1 | All times are UTC + 1 hour |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |