macklebee

try this: require("Scripts/constants/engine_const") require("Scripts/math/math") RegisterAbstractPath("") Graphics(800,600) fw = CreateFramework() fw.main.camera:SetPosition(Vec3(0,1,-5)) light1 = CreateDirectionalLight() light1:SetRotation(Vec3(45,45,0)) scene = LoadMesh("abstract::scene.gmf") gx=Round(GraphicsWidth()/2) gy=Round(GraphicsHeight()/2) MoveMouse(gx,gy) camerapitch=fw.main.camera.rotation.x camerayaw=fw.main.camera.rotation.y HideMouse(1) while KeyDown(KEY_ESCAPE)==0 do dx=Curve((MouseX()-gx)/4.0,dx,3.0/AppSpeed()) dy=Curve((MouseY()-gy)/4.0,dy,3.0/AppSpeed()) MoveMouse(gx,gy) camerapitch=camerapitch+dy camerayaw=camerayaw-dx fw.main.camera:SetRotationf(camerapitch,camerayaw,0) move = Curve(KeyDown(KEY_W) - KeyDown(KEY_S), move, 10) strafe = Curve(KeyDown(KEY_D) - KeyDown(KEY_A), strafe, 10) fw.main.camera:Move(Vec3(strafe/10, 0, move/10)) fw:Update() fw:Render() Flip(1) end

Single means all the animations are in one animation loop. Multi means they have been separated out. Single on the left. Multi on the right. Single is typically what you would use with LE. But the Multi version is nice because then you can easily export out separate animations like what was done with the LE soldier. It allows you to load only the animations that you want plus apply those animations to other models assuming they have the exact same bone hierarchy. NOTE: The animation editor is in Ultimate Unwrap 3D, not Leadwerks.

should be: cube = CreateCube() call the ground a different variable or it will rotate the ground in the main loop. also, the main loop should have one 'fw:Update()' and one 'fw:Render()', not two 'fw:Render()'.

If i understand the question in your post title, you are just trying to get the texture that is associated with the object that you picked... A pick's structure includes a surface. See here. If you have a surface, you can use GetSurfaceMaterial() to obtain the material. See here. And with GetMaterialTexture(), you get the texture from the material. See here. EDIT -- if your question is to get the UV coordinates from a pick, then look at klepto's TAdvancePick

thats ok... i think i will just stick with 3 lines of code...

do you do garbage collection any where in your script? see this post that had the same problem with the viperscript and the modified oildrum scripts: http://www.leadwerks.com/werkspace/topic/2178-mem-usage-grows-continuously/page__view__findpost__p__20049

see this post: http://www.leadwerks.com/werkspace/topic/3468-243-terrain-texture-render-problem/page__view__findpost__p__31539 which leads to the bug reports located here:http://www.leadwerks.com/werkspace/tracker/issue-165-terrain-textures-bug-radeon-hd-5850/ and here:http://www.leadwerks.com/werkspace/tracker/issue-180-ati-bug-ground-still-there/ Install an older ATI driver for the time being, like AMD Catalyst 10.1.

looks great Gandi... i was wondering where you had disappeared to and was doing... very cool. concerning the decal script, you may want to be aware of this bug in LE2.43: http://www.leadwerks.com/werkspace/tracker/issue-187-terrain-resolutionmeterspertile-not-working/ I found that due to your decal script. So maybe set the values by selecting as a property dialog in the script?

Yes, your LOD model will need to be textured as well but you could just use the same texture. A LOD model is still a model just lower poly than the main model, so you still have to treat it as such. Look at the oildrum in the SDK to see how it is accomplished.

if you are just after the texture, could you not just use a combination of pick.surface, GetSurfaceMaterial(), and GetMaterialTexture()?

try replacing the last line: gl_FragData[0] = (lightcolor * diffuse * attenuation * shadowcolor) + (specular * shadowcolor); with this: ambient = gl_LightSource[0].diffuse * (1.0-falloff) * 0.25 * diffuse; gl_FragData[0] = ambient + (lightcolor * diffuse * attenuation * shadowcolor) + (specular * shadowcolor);

No. The code i showed above returns the GMF model's folder path. c:/program files/leadwerks engine sdk/models/props/oildrum/oildrum.gmf The GetEntityKey(e,"name") returns a model's name key, assuming it even has that key. oildrum_1

oh yeah... i forgot all about that... it returns the same thing For e = EachIn fw.Main.world.entities If GetEntityClass(e) = ENTITY_MODEL Then Print(MeshName(TMesh(GetChild(e, 1)))) End If Next

i can do it in bmax... so maybe that will help with a c++ version? For e = EachIn fw.Main.world.entities If GetEntityClass(e) = ENTITY_MODEL Then Print(TModel(e).reference.path) End If Next

Well there is definitely an issue there but i am not sure what to make of it. If I just save a framework rendered buffer to PNG there is no issue... it looks correct.

awkward? personally i like the effects... i sure as hell wouldn't have wanted to try to get them to work on my own. which is if i remember correctly, is the whole reason josh did the framework and made it available to us because no one was achieving these effects on their own.

I think it has something to do with the PNG format... I am getting weird results with it. If I look at the resulting png screenshot in MSPaint, it looks fine. If I look at it with Windows Photo Gallery, the terrain and sky are white. If I open it with Gimp (where the entire scene is covered by a transparency checkerboard) and save it to another format (JPG), the terrain and sky are whited out. If I use TGA for the file format to save the buffer to, it appears to work ok.

i dont know because i have never tried it personally... my modeling/animation skills right now are making a cube bounce up and down

well it depends i guess on whether or not the gloves and helmet will be coming off alot... if they are going to be permanent then its probably easier just to make them part of the model to begin with... if say the helmet can get knocked off, then i would probably just live with the few extra polygons hidden by the helmet, especially since LE can handle large amounts of polys being rendered relatively well. Or you could do what alot of games do, and make the head a separate attachment. As for the armor, i think most games cheat when it comes to that by making the armor not interfere with any of the arms/shoulder animations... granted i am only guessing because i am far from being a character modeling expert. in any case, attaching a helmet to whatever bone controls the head's position/rotation should work just fine as long as you setup the helmet's initial position/rotation correctly for the un-animated pose just like i did for the sword.

eh, it happens... i totally missed it as well when i looked at the post the first time and apparently so did others... i just knew that parenting objects to the bones has worked for me in the past and i wanted to test to make sure something hadn't broken with any latest releases...

Mike, you can still access the waterpatch in LE 2.43 with Framework in bmax and lua. fw.renderer.waterpatch but it requires the waterplane to be rendered at least one time (ie. fw.Render() ) before you can access it. btw, that looks extremely nice

That is not true. I can set every bone in the model to have a sword attached to it and the animations work fine. You are breaking the bone hierarchy in your code which is why the animations do not work any more. You are setting the sword as the parent to the spine. The proper syntax for EntityParent() is: void EntityParent( TEntity entity, TEntity parent, int global=1 ) as shown here: EntityParent()

you should post the code as well in the demo and in the bug report... this could very well be an issue of implementation.

that above is from parenting but since the crawler model's hand is already at a rotated angle, I had to position and rotate the sword just initially after I set the parent to make it look correct. Afterwards, just playing the animations made it follow the hand correctly. I moved the origin of the sword to the handle and changed the orientation so the blade is pointing up (mostly because it just made more sense for me to set the angle that way). medievalweapons_longsword.zip then i attached the sword by using this for the crawler script: require("scripts/class") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) object.hand = object.model:FindChild("Bip01 R Hand") if object.hand~=nil then object.sword = LoadModel("abstract::medievalweapons_longsword.gmf",object.hand) object.sword:SetRotation(Vec3(230,-20,0)) object.sword:SetPosition(Vec3(.12,.05,-.05)) end end as for your video, i have no idea why that would happen... i have not had that issue. its almost like the bone hierarchy has been broken... did you by chance set the sword as the parent of the bone? dunno... weird. EDIT*** - uploaded the wrong sword...

parenting works decent for me so far for what i have tried. i suspect setting a sword to the crawler's hand would have been easier if the crawler had a tpose as the initial unanimated pose.