klepto2

@enablerbr: thx i will definatly look into this and add this. I have tried something similar bug gave up as i have seen the TAO and OpenTK Controls. But I think a native control may be the best solution to be independent from others. I haven't tested it with the express editions yet but normally there should be no problem. Keep in mind to copy the needed dlls from leadwerks into the release folder if they are not automatically copied. Also you may test if the target platform is really X86 and not AnyCPU or X64. @ZeroByte: Yes the control should work in vb.net as well (all .net languanges should be able to use it @All: Keep in mind that this is still beta. I'm currently try to figure out how to use framewerk with the controls and some other stuff i have in mind. I'm also revisiting my own old (2.25 based) Wrapper which has a more bmx oriented Object Layout. (See Image below)

Hi, I'm currently writing / continueing the C# Headers and found no way to set the target buffer of the framework. This may be needed to be able to use the CustomBuffers with Framewerk (eg: a LEControl). If there is already such functionality, please tell me.

new Headers with source are available: Leadwerks C# Headers next on todo: fixing Vehicles

How about saving it as png and then using the freeimage lib to convert it to dds? Of course it would be nice if Josh includes the dds saver but in the meantime this might be a solution.

Yes, you just drop the control as every other control in your form. the Custombuffer is automatically created. The control will provide 2 extra events. 1. OnInit: In there youinitilize your objects, framewerk etc. 2. OnUpdate: In there you update the code ( no Flip needed as it this is done autmatically) You only need to keep track of your own buffers via the resize events. Both the TAO Control and the OpenTK Control are working exactly the same as the control, so you can swap the controls without changing the underlying code. (I prefer the OpenTK as it is still continued and already offers OGL4.0). I still need to fix some issues. But I think i will upload my version the coming weekend.

Sorry to hear that you don't have time to continue on this, I will continue working on the delegates and some other functions which are currently missing or named wrong. I also have 2 working Leadwerks Controls (1 for the TAO Framework and 1 for the OpenTK lib). I will post the new files as soon as possible.

I'm still working on this issue, but for the meantime you can surround the UpdateWorld command with a Try Catch Block. Not elegant but it seems to work.

No, but I need to to investigate a bit further. If i remember correctly there was a need to Marshal the structs. Yesterday I wasn't able to solve it but hopefully i will solve everything over eastern weekend.

Hi, I will start today to implement the missing functions (As long as i find everything) If someone is functions/delegates he/she is missing in the current release please post them here. So I'm able to better find the missing functions. Also I will add a Leadwerks Control and send it to Ubu, maybe he will add it to the main assemblies. @Rekindeled Phoenix: This needs some investigation, I remember that it works without issues in the old wrapper maybe something with the delegate definition is wrong.

It seems you're not yet unlocked for the 2.3 SDK release. As you see you're still in the SDK 2.0 Group. If that changes to 2.3 Owner or the like then you will be able to download the 2.3 release. I don't know when you have purchased the update but keep in mind that the purchase is not an automated process and Josh needs to register it manually.

Very Good work the design looks really nice. I have 3 things I would like to see asap: Core.GetSize needs to be: public delegate void GetSize(ref int _width,ref int _height); CustomBuffers are missing (I need them for a Leadwerks Gui Control) class Buffer is colliding with System.Buffer and needs to be resolved with Leadwerks.Buffer. My first OOP Model was based on the bmx class design to keep the source nearly identical a small class diagram:

yeah, by the way: bmx is open enough to integrate it. I have written ides and debuggers for bmx so if you need a hand on this part i will of course help. Maybe it will become a good bmx ide replacement and alternative to Blide. But all in all your vision looks promising. I hope you can make it true.

I know what you mean and I also think VS IDE is the best IDE out there. And I think your idea isn't bad but why using an IDE based on VS Shell when eg for C++ or C# developers a complete set of tools is already given and are more tested? Don't get me wrong, I will be happy if you can proove me wrong

The idea itself sounds good, but i doubt that anything produced with the sdk will have the same comfort as the various IDEs available. Also I believe Leadwerks should concentrate to bring the engine to the next level (new tools, features etc). An IDE for every language (or even the most supported) will only disapoint users coming from other specialized IDEs (IMHO).

Forget the linepicking if you want it to update in realtime. I don't know whats going wrong with the terrainElevation function but it looks much less accurate as it should be. For a single patch it linepicking slows down to 2 - 5 fps, so no option. I will look a bit deeper in it as i need this function myself.

material: texture0="abstract::sun.dds" clamp0=0,0,0 blend=1 depthmask=0 depthtest=1 overlay=1 zsort=1 cullface=1 castshadows=0 specular=1.00000000 bumpscale=1.00000000 gloss=0.500000000 shader="abstract::mesh_diffuse.vert","abstract::mesh_diffuse_alphablend.frag" shadowshader="abstract::mesh_shadow.vert","" As MasterXilo already said, if you use alphablend textures within the mainworld it can produce unwanted effects. eg if you use this material in the mainworld you would just see brighter legs of the model but nothing on the terrain. Building it as a shader is my next step. I have done it with my own engine previously and i know it is more accurate then the non gpu approach.

Of couse you can paint it with a material I will work on it a bit more and then I will post it in the archives.(I planned this feature for later but now i can also finish it;) ) there are some issues if the terrainelavtion is not giving exact values. Also you may need to set it to the transparent world if you need to use alpha textures like the above.

I have put together a small prototype in my test application (Blitzmax) : And thats the code of the class: Type TTerrainPlane Global list:TList = New TList Global terrain:TTerrain Field Mesh:TMesh Method New() list.AddLast(Self) End Method Function Create:TTerrainPlane(parent:TEntity, Scale:Float = 1.0) Local p:TTerrainPlane = New TTerrainPlane p.Mesh = CreatePatch(32, 32, parent) ScaleMesh(p.Mesh, [scale, 1.0, Scale]) MoveEntity(p.Mesh, [- Scale / 2.0, 0.0, -Scale / 2.0]) Return p End Function Function SetTerrain(t:TTerrain) TTerrainPlane.terrain = t End Function Function Update() If terrain = Null Then Return For Local Plane:TTerrainPlane = EachIn list Plane.Calculate() Next End Function Method Calculate() For Local Si:Int = 1 To Mesh.CountSurfaces() Local surf:TSurface = Mesh.GetSurface(Si) For Local Vi:Int = 0 To surf.CountVertices() - 1 Local vertex:TVec3 = TFormPoint(surf.GetVertexPosition(Vi), mesh, Null) ; Local newpos:TVec3 = Vec3(vertex.X, TerrainElevation(terrain, vertex.X, vertex.Z) + 0.01, vertex.Z) surf.SetVertexPosition(Vi, TFormPoint(newpos, Null, Mesh)) Next Next End Method End Type Function CreatePatch:TMesh(xsegs:Int = 1, zsegs:Int = 1, parent:TEntity = Null) Local x:Int,z:Int Local mesh:TMesh Local count:Int Local surf:TSurface mesh = CreateMesh(parent) surf=mesh.AddSurface() For z=0 To zsegs For x=0 To xsegs count=surf.AddVertex([Float(x)/Float(xsegs),0.0,Float(z)/Float(zsegs)],[0.0,1.0,0.0],[Float(x)/Float(xsegs),1.0-Float(z)/Float(zsegs)]) If x>0 And z>0 surf.AddTriangle(count-1,count,count-xsegs-1) surf.AddTriangle(count-1,count-xsegs-1,count-xsegs-2) EndIf Next Next mesh.Update() Return mesh EndFunction Maybe this helps.

There is another Terrainfunction called TerrainEvaluation, this will give you the correct height value. the terrainheight function must be muliplied by the terrain y-scale value. x,y = x,z it is just y because you actually read from a texture in 2d space not 3d. the interpolation is because calculating the correct value (eg: fining the correct chunk, finding the correct triangle and then finding the point in triangle) is far to slow for these kind of things. The interpolation takes the 4 nearest full pixel values of the point (the point itself is a float) and performs a cubic interpolation between these points (weighting is based on distance from the real point to the full pixel). This technique is much faster and as long you don't have really oversized tilesizes it is accurate enough.

I missed your 3rd point where you handle the height issue (which will result in the 1 long raycast I've mentioned). As said: I would go the "terrainheight" way or the shader way. But there is also a cheaper raycast method: Do it the other way round ! Do a raycast from the vertex position at zero level (x,<=0, z) and do raycast up to the real vertexposition. Now just add an offset and you will have the same result but with generally lower raycast lengths. Well the number of raycasts depends on the pc the application is running on. It can run smooth with yours but can be very slow on other machines.

Doesn't sound bad but doing a raycast for all vertices may cost lots of cpu power. Remember that you need 2 raycasts with short ranges or 1 with a range of maximum terrainheight - vertexY because you don't know if the point is above or below the terrain. I believe you have 2 options here: 1. Use directly the Terrainheight function which interpolates the height at given points / may be also cpu heavy and depends highly on used vertices. 2. Write a meshshader which aligns the vertices on thy fly to the terrainheight. Terrainheightmap and everything else needed for this should be available in the shader pipeline.

I would try to make my own CreatePlane function. Somewhere in this forum was a sample function posted by Josh (maybe the old forum). Also you may have a look at the road script. there you find code how to morph / align vertices to the terrain height. for optimal results you have to adjust the vertex spacing to fit the terrain resolution. Also there was a thread about terrain decals (by TylerH if i remember correctly) which looks like the thing you want.

I'm currently working on my loading and setup routines and I think it may be useful to have some kind of callback for the LoadScene function. Currently my scene is relatively small and small splashscreen is enough for indicating loading. But i if the scene files grow and the loading of a scene takes much longer i would like to present progress on my loading screen. Maybe you can add a callback as an optional parameter to the loadscene function: main_scene = LoadScene("abstract::map_x_1_y_2.sbx", LoaderProgress) Function LoaderProgress(progress:TSceneProgress) DrawImage(splash, 512.0 - loadimg.Width() / 2.0, (768.0 / 2.0) - (loadimg.Height() / 2.0)) Local total:Int = progress.GetTotalItems() Local loaded:Int = progress.GetLoadedItems() DrawText "Loading... " + (loaded / Float(total)) * 100 + "%",20,20 Flip() End Function

this works really great ! thx.

thx. http://www.dexsoft-games.com/models/fantasy_warrior.html