macklebee

thats great for people who have a modeling application that actually exports to fbx...

the character model is not really what i would call useable for a game... once converted it has over 150,000 polygons. and it looks like you forgot to do smoothing as the model's polys are real jagged... and the reason the model seems strange is because all of the surface normals are flipped incorrectly...

That feature was asked for already to Brad Bolthouse of UU3D. Brad implied that it would require him to rewrite uu3d along with the gmf exporter... something he was not keen on doing. You can get mesh hierarchy in UU3D if you export as b3d then use the b3d2gmf converter, but it will suffer from setting all of the submeshes' origins to 0,0,0. Suggest you try the AutoDesk fbx converter as shown in wayneg's blog if you wish to keep mesh hierarchy: http://www.leadwerks.com/werkspace/blog/36/entry-725-the-art-pipeline-google-sketchup-the-fbx-converter/

try this: require("scripts/class") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) object.model:SetKey("Surface","Concrete") end and probably in the C code, you would need to find the model of the pick.entity as a pick's entity is a mesh not the model...

ok... does the model actually have more than one material assigned to it? you can open it up inside the ModelViewer and see if there are multiple surfaces with different materials... As for assigning different materials you can just write the lua code that would set the materials for a specific surface... but without seeing the model and textures, we would just be guessing... also keep in mind that if you change the material texture for one model it will change for all of the models...

what editor? The LE2 Editor? It is not a modeling application... its a scene editor... what are you using to create the model? 3dsmax, blender? post your model and textures... EDIT-- Are you referring to the lua Properties dialog? and the material property?

you do this in your modeling application... just use multiple textures for your model instead of one... then use a material file for each texture used after its been converted to GMF so for your example: you must have a material file for the clothes texture and a material file for the skin texture... but these surfaces must already have been assigned these textures from the modeling application...

yes.

just simply select the leadwerks module in the 'Configure modules database' from the Modules pulldown menu then use the 'Document modules' from the same pulldown menu. you might have to restart blide for it to take effect...

The math.lua file is located at "scripts/math/math.lua" not "scripts/math.lua" in the standard SDK. So if you have a script that is calling: require("scripts/math") then it would cause this problem. Also, unless your car model has mesh heirarchy like the viperscout then the viperscout script would have to be rewritten to locate the wheel locations.

if he is just wanting the model, i think he should be able to simply use what Chris Paulson used and what I had just posted last week here: TBody GetMeshModel(TEntity entity) { std::string classname; while (entity!=0) { classname=GetEntityKey(entity,"class"); if (classname=="Model") { return entity; } entity=GetParent(entity); } return 0; } EDIT - I see you edited your response before I finished posting - but yes, that should basically work as it appears it worked for Chris and paratoxic...

has this been changed recently? as GetEntityType() previously returned the collision type not the entity class...

you would have to use the equivalent lua command for modulo, which would be: frame = math.fmod(frame, frameend - framebegin) + framebegin or frame = frame % (frameend - framebegin) + framebegin and you would not need the object script if you use this... but that is the whole purpose of the object script. Also, you could have easily just used the equivalent code from the object script inside this standalone script.

er-- why not use the object script i showed you the other day for your model? but in any case, look at this line: frame=frameend-framebegin+framebegin essentially you are just setting the frame variable to frameend each time... you need to cycle the frame value like this: frame = (frame Mod (frameend - framebegin)) + framebegin granted this just one way to do it... there are plenty of ways to calculate the frame parameter for the Animate command...

in the example you link to in your post, the graphics context is not by the LE Graphics() command but rather a maxgui canvas on a maxgui window... so you would have to resize the window. the best option then is to set the canvas size as a relationship to whatever the size the window is currently... if you search the Blitz forums for 'fullscreen' there are several examples and ways found there to do this with maxgui commands...

in 3dws using the default scale conversion that is used with the inherent exporter, a 128x128x128 box in 3dws is equal to exactly 1x1x1 meter box in LE. use the '[' & ']' to change grid size in 3dws of the active orthogonal window - suggest you look at the Key Shortcuts listed in the Help file - granted all of these are shown as well from the pulldown menus...

the asset store has a lua example of loading animations into the soldier character:http://www.leadwerks.com/werkspace/files/file/225-lesoldierentityandgamezip/ make sure you grab the latest soldier.lua script that has the changes needed to work with the latest SDK: http://www.leadwerks.com/werkspace/topic/4129-animation-with-lods/page__view__findpost__p__36451

yes you are right - I meant that it is supposed to do this according to original intent... and how it will be done once Josh actually fixes it. It looks like josh has taken it the opposite way when he "fixed" the bug... before i believed it only was effected by the terrain layer texture and now it appears its only effected by the basemap texture... oh well - he has responded to it in the bug tracker so hopefully it will be a quick and dirty fix that he can do along with DebugJoints()... so expect to have it fixed by tonight! EDIT-actually before the grass was affected by the terrain layer textures when there was no basemap and if there was a basemap, then the basemap was the only thing that effected the grass color... now it looks like he changed it so only the basemap effects it with no regards to the terrain layer textures

The base texture can be any texture you want... it has nothing to do with a grass material file. The grass material file just uses a shader that allows the grass to be colored based on the blending of the base texture and the terrain layer textures. Just select a base texture and then adjust the blend of your other terrain textures to see the base texture blended in...

ok fair enough. well there were others that had posted questions and concerns about joint stiffness as well... and considering one of the people posting it as a big concern to them is creating one of the flagship games for LE, i would have thought it you would consider it an issue...but that's fine. The visualization of joints and pins is something that I would suggest no matter what physics library is used as it would help everyone and I wasn't suggesting it be handled by the library. So... only one hour to set up? Cool! I cannot wait to try it out tonight!

non-SDK owners can only download from the Demos and Games section of the Asset Store.

well you could just post your game sdk so we can play it!

you or cassius should make a bug report on the lack of basemap causes color issues as Josh tends to forget about stuff unless its posted in the Bug Tracker screaming for his attention...

is it available to play?

ok... 1) Now that you have scaling working, can we expect to get the scaling ability in LE2 as this has been a sore subject and issue for as long as I can remember? 2) While soft bodies would be nice, its the joints that concern me. You have already stated that the joint stiffness problem is beyond your capabilities. And the joint commands are currently a pain to deal with as the parameters are not clearly defined nor or are there good examples to learn from... an idea that might be beneficial to all is the ability to actually see the joints/pins with a command like DebugJoints()... then at least we could visually see how the parameters affect location and rotation of joints... and more of just a comment than anything... but isn't it a little crazy to still use newton just for the people that come here for the delusion that they are going to make a huge open terrain MMO or flight sim by themselves?