|
Post by HartZa on Apr 17, 2005 8:43:16 GMT 1
I noticed that Newton doesn't work with hi-poly objects. I've tried to put the limb-thingy to 1 instead of 0, but it doesn't help. Is there any way to get it to work? When I try to execute my project, it starts to compile it, starts the program, gives me a black screen and after a while it exits. The object I have tried to use with Newton is 1500x1500 terrain object with a big amount of polygons. I know that the problem is not anything that I've could mistakenly do, since the Newton works with low-poly objects. Anyone could help me? I'd appreciate it.
|
|
ec3t
Newton Scholar
Posts: 103
|
Post by ec3t on Apr 17, 2005 13:00:55 GMT 1
I have the same problem , terrain crashing and exiting , and i did point at the terrain myself too
the thing is , with update 5.7 it worked , and with 5.8 not , you point at the poly number , i say this comes from the terrain plugin ... wanna try to find out with me ? let's contact over msn maybe ?
in any case we should make this officialy a bug , if we want kjelle to take care of this
|
|
ec3t
Newton Scholar
Posts: 103
|
Post by ec3t on Apr 17, 2005 16:44:06 GMT 1
ok i tested with a scale of 1,1,1 , it fizzles , Hartza is definitly right , my terrain prob is also a poly problem , if i try with a 508000 poly terrain , that would fizzle , thanks again ... i've been on it for 3 weeks now ......... trying to get it fixed
kjelle ..... try to test a terrain with a bitmap of 505x505 , it will make 508000 poly ... you will see it will fizzle
|
|
|
Post by HartZa on Apr 17, 2005 18:16:10 GMT 1
Good to know there's other people too who haves the same prob. I have the 5.8 version too, but I didn't try those high-poly terrain objects on earlier versions. My terrain has about 600 000 polys, which is a little more than yours, but still both does the same. Hopefully kjelle tries to work on this, at least I hope so! PLEASE KJELLE, save our souls!
|
|
ec3t
Newton Scholar
Posts: 103
|
Post by ec3t on Apr 17, 2005 18:32:10 GMT 1
anyway we will do a strike if he doesn't right ? ;D
"We waaant polys , we waant polys , weee want them now "
|
|
|
Post by Kjelle69 on Apr 18, 2005 4:02:35 GMT 1
there are plenty of ways to get it working ON YOUR OWN, without asking for kjelle to "fix" the wrapper.
the problem has all along been the same: the wrapper internally uses some DBPro commands to create TreeCollisions. here's the process:
1) Make a copy of the object to be used. 2) convert the FVF of the new copied object to "2", which means vertex positions only. this saves on memory. 3) make a mesh from the object from step 2. 4) make a memblock from the mesh in step 3. 5) create a new TreeCollision object. 6) cycle through all the polys in the memblock, adding them to the TreeCollision with the AddFace command. 7) finalize the TreeCollision object.
that's it. the problem is that DBPro has a limit on the size of memblock, so if you use a mesh that is too large, it crashed on step 4. the alternate ",1" method does all of the steps above, but instead of doing the entire mesh at once it does it limb-by-limb, creating a new object from each limb. this again only works if each limb is small enough to fit in a memblock.
SOLUTIONS YOU CAN IMPLEMENT ON YOUR OWN-
although I don't use DBpro lately, I think the new 5.8 included commands that let you access vertex data of objects directly. if this is the case, just do this in your code:
1) create new, empty TreeCollision object. 2) cycle through all polys in your object, getting the location of each vertex with the new commands, and adding the poly to the TreeCollision. 3) finalize the TreeCollision.
that's it. someone please give it a try. if it works, make it into a simple function for everyone else to use and post it.
that should solve the problem, which has nothing to do with Newton or the wrapper, but instead the limitations of DBPro. when the wrapper was originally written, there were no commands to access vertex data safely, so the memblock approach was used.
|
|
|
Post by HartZa on Apr 18, 2005 5:53:46 GMT 1
Thanks, Walaber! I'll test this later when I have some time, hopefully it works.
|
|
ec3t
Newton Scholar
Posts: 103
|
Post by ec3t on Apr 18, 2005 7:32:55 GMT 1
Ok cool , but i still will report the bug as one , since the datatree is broken for high polys and i do think it's your purpose not ours to fix the wrapper scall yourself the creator of it and don't let kjelle be administring it .
|
|
|
Post by zircher on Apr 20, 2005 19:41:27 GMT 1
[rant] Man, there's something about ec3t that just gets under my skin. Apparently, he's immune to the facts.
I would suggest removing the tree commands from the wrapper have him use .X models. Problem solved. But, that's not my call. I'm quite grateful for what Newton and the wrapper already does.[/rant] -- TAZ
|
|
ec3t
Newton Scholar
Posts: 103
|
Post by ec3t on Apr 20, 2005 22:02:43 GMT 1
well , if one day you get replied from the car seller that you have , that the tire you have exploded and got you to a wall crash , that you had to check the notice before use and read line 11 and a half to see that the tire were actually sold broken , you would , like i have , react quite badly , everything seems to work for now for you , perfect , you wait until the day come , and remember , don't shout that day .
|
|
|
Post by Kjelle69 on Apr 21, 2005 7:55:57 GMT 1
get a grip man. Newton is free. the wrapper is free. I and Kjelle and the makers of Newton have done nothing but work hard to give YOU free stuff, and then when you have problems we all give you answers and suggestions and you still complain.
that's just ridiculous. if you're not willing to look for a solution, and instead wait for someone else to fix it, you'll never make anything worthwhile.
ugh.
|
|
ec3t
Newton Scholar
Posts: 103
|
Post by ec3t on Apr 21, 2005 8:00:42 GMT 1
I will let time decide
|
|
|
Post by IceNine on May 1, 2005 9:47:12 GMT 1
'Lo ! Just built this, works with a 300K poly object with 7 limbs here, hope it does the same for you. Maximum poly - If DBP can load it, it should work. Maximum Limbs - 254
Hope this helps you folks out.
EDIT - Seems to work fine with .X objects, but DBO files give a tiny collision model? I'm assuming they're internally scaled and the vertexcommands don't see that.
Function DBObj2TreeCol(TargetObj as Integer) `give an object number, get back a tree collision number `Object must have fewer than 254 limbs for this to work
`vars Dim tri(2) : Dim Pnt(2) as Float : Dim Mins(2) as Float : Dim Maxes(2) as Float `for world sizing after Mins(0) = -100.0 : Mins(1) = -100.0 : Mins(2) = -100.0 Maxes(0) = 100.0 : Maxes(1) = 100.0 : Maxes(2) = 100.0
perform checklist for object limbs TargetObj Passes = Checklist Quantity() Empty Checklist
`init the tree build in newton TreeCol= NDB_NewtonCreateTreeCollision() NDB_NewtonTreeCollisionBeginBuild TreeCol
For T = 0 to Passes-1 `lock the object vert data for transfer Lock VertexData For Limb TargetObj,T Indices = Get VertexData Index Count() for I =0 to Indices step 3 `grab 3 verts tri(0) = Get IndexData(I+0) tri(1) = Get IndexData(I+1) tri(2) = Get IndexData(I+2) `NDB_SetVector seems to require explicit vector declaration, so this `has to be done the long way `Point 1 Pnt(0)=Get VertexData Position X( Tri(0) ) if Pnt(0) < Mins(0) then Mins(0) = Pnt(0) if Pnt(0) > Maxes(0) then Maxes(0) = Pnt(0) Pnt(1)=Get VertexData Position Y( Tri(0) ) if Pnt(1) < Mins(1) then Mins(1) = Pnt(1) if Pnt(1) > Maxes(1) then Maxes(1) = Pnt(1) Pnt(2)=Get VertexData Position Z( Tri(0) ) if Pnt(2) < Mins(2) then Mins(2) = Pnt(2) if Pnt(2) > Maxes(2) then Maxes(2) = Pnt(2) NDB_SetVector 1,Pnt(0),Pnt(1),Pnt(2) `Point 2 Pnt(0)=Get VertexData Position X( Tri(1) ) if Pnt(0) < Mins(0) then Mins(0) = Pnt(0) if Pnt(0) > Maxes(0) then Maxes(0) = Pnt(0) Pnt(1)=Get VertexData Position Y( Tri(1) ) if Pnt(1) < Mins(1) then Mins(1) = Pnt(1) if Pnt(1) > Maxes(1) then Maxes(1) = Pnt(1) Pnt(2)=Get VertexData Position Z( Tri(1) ) if Pnt(2) < Mins(2) then Mins(2) = Pnt(2) if Pnt(2) > Maxes(2) then Maxes(2) = Pnt(2) NDB_SetVector 2,Pnt(0),Pnt(1),Pnt(2) `Point 3 Pnt(0)=Get VertexData Position X( Tri(2) ) if Pnt(0) < Mins(0) then Mins(0) = Pnt(0) if Pnt(0) > Maxes(0) then Maxes(0) = Pnt(0) Pnt(1)=Get VertexData Position Y( Tri(2) ) if Pnt(1) < Mins(1) then Mins(1) = Pnt(1) if Pnt(1) > Maxes(1) then Maxes(1) = Pnt(1) Pnt(2)=Get VertexData Position Z( Tri(2) ) if Pnt(2) < Mins(2) then Mins(2) = Pnt(2) if Pnt(2) > Maxes(2) then Maxes(2) = Pnt(2) NDB_SetVector 3,Pnt(0),Pnt(1),Pnt(2) `add face to tree NDB_NewtonTreeCollisionAddFace TreeCol Next I Unlock Vertexdata Next T `close tree NDB_NewtonTreeCollisionEndBuild TreeCol,1
`set the world size to encompass the tree `Might be a good idea to store these elsewhere as well for later NDB_SetVector 1,Mins(0),Mins(1),Mins(2) NDB_SetVector 2,Maxes(0),Maxes(1),Maxes(2) NDB_NewtonSetWorldSize
`if you want to save the serialization, here would be a good place to add... `NDB_NewtonTreeCollisionSerialize TreeCol,"Serial.Dat" `...then just load the saved serialization next time.
UnDim tri(0) : UnDim Pnt(0) : UnDim Mins(0) : UnDim Maxes(0) endfunction TreeCol `**
#nosmileys#nosmileys
|
|
|
Post by Kjelle69 on May 1, 2005 12:05:22 GMT 1
thanks! that's exactly what I was talking about
|
|
ec3t
Newton Scholar
Posts: 103
|
Post by ec3t on May 1, 2005 13:56:42 GMT 1
thanks icenine I'm gonna stress test this new command you helped me really much
|
|