Lupin

Thanks for the explanation, I feel embarrassed that I haven't followed the news for a while. I watched the video, it's great stuff and I'm really glad that the engine went in this direction.

Really? A nice surprise, I must have missed some memo... ;-) Is this currently the default backend or only for Intel/AMD? My point is that I would personally prefer OGL on NVidia as well due to the pre-GTX 9xx models (if it were possible, OGL 4.6 is supported from 14-year old 4xx).

Maybe I missed something, so I would like to ask if Ultra, in addition to Vulkan, has a planned OpenGL 4.6 backend ? I wouldn't have bothered you with this question if I hadn't noticed the mention in the thread: Personally I think that such an "legacy" backend would be a reasonable addition. This would provide the potential ability to run applications on a wider hardware base, so engine would therefore be an solution not only for games requiring high performance, but also for casual indie games, including retro-style. Anyway, if this is indeed the plan, would it be possible in future to select/force the engine to use a specific backend on initialization (something like: use OpenGL, Vulkan or Auto/default)?

Where's the best place to report minor mistakes in the documentation - here, on the forum (in bug thread?) or on GitHub? So far, I noticed that according to the documentation, functions that create lights return nothing (which can be confusing). void CreateBoxLight(...) void CreateSpotLight(...) void CreateDirectionalLight(...) While the one below is described correctly: shared_ptr<PointLight> CreatePointLight(...)

Tahnks for replies. After reading, I realized that instead of describe the problem, I wrote an observation, that I (mistakenly) thought explained the source of the problem. A potential bug, as correctly described Dreikblack, is that: Once a window has been created, it cannot be physically closed other than by completely terminating the program. I think this is a minor, low priority thing, but could be looked into at some point. Or maybe there is a workaround? #include "UltraEngine.h" #include <iostream> #include <chrono> #include <thread> using namespace UltraEngine; void RunTestProc() { auto window = CreateWindow("Ultra Engine", 0, 0, 800, 600, GetDisplays()[0], WINDOW_CENTER | WINDOW_TITLEBAR); auto world = CreateWorld(); auto framebuffer = CreateFramebuffer(window); auto camera = CreateCamera(world, PROJECTION_ORTHOGRAPHIC); while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { world->Update(); world->Render(framebuffer); } window->FlushKeys(); window->FlushMouse(); FlushEvents(); std::cout << "before exit func window.use_count = " << window.use_count() << std::endl; } int main(int argc, const char* argv[]) { RunTestProc(); // theoretically there are no user object references left at this point, so the window should be closed ? // but it is still open, although non - functional. std::this_thread::sleep_for(std::chrono::milliseconds(1000)); // just to be sure... Print("\nCan you still see the window?\n"); system("pause"); return 0; } It seems to me that some resources are not being deleted, even though all user-created references have gone out of scope. Perhaps they are what keep the window alive?

The reference counter in smart_ptr<Window> increments with each input event, e.g. mouse movement, key presses, etc. Seems like, it stops after reaching the number of 1005 references (the program continues to work normally). This doesn't seem to be a problem, but it may be a sign that there is an small bug somewhere? You can check this by adding inside the render loop: window->SetText(WString(window.use_count())); Latest dev build, checked on Debug and Release. I didn't notice anything similar with other objects.

Tumira, I experienced frame jerks on similar hardware setup. In my case, I noticed that with VSync ON, one of the 8 processor cores still uses near 100% (while others at 0%). I solved the problem by setting DISABLE "Multithread Optimization" in Nvidia control panel. Now, when VSync is enabled, at 60 fps every core is utilized near 0% (well, maybe bit more), and single-threaded OpenGL apps like Leadwerks runs far smoother, without any jerking. I hope this helps maybe in your case too.

I think there will be some basic intellisense, at least for API LE3. See here: http://www.leadwerks.com/werkspace/page/gallery/_/intellisense-and-breakpoints-r111

In 3DWS in vertex mode you can also select and move edges by clicking and dragging the yellow edge tabs. I think here it's the same - easy and intuitive way.

That great news! Could you possibly clarify: these estimated timeframe are for final, public release? Or rather beta version (or pre-release, pre-alpha, etc..) - eg. for testing by current users?

Amazing news. As an old user of 3D World Studio I simply love these new features. And I can't wait for the day when I can check them out in practice. One question - Do you anticipate the possibility of of converting a group of brushes into the model (mesh) within editor? This could be useful as an option to create prefabs.

so, when it comes to human experimentation (pre-alpha build or something), I'm ready And, If I could have a small request: Current 3DWS 5.x has "texture lock" feature, that works globally - on all scene brushes. Whether it would be possible to add a flag "lock UV" at the brush level ? I mean bitwise flag (similar to smoothing groups concept) for preventing UV changes on scale / rotation / position for selected brushes?

Witawat, If I correctly understand, you try to make executable by compiling API header file only, right ? Wrong way. Look at my answer to your post in 3D Artwork section, I hope this helps.

witawat, If You are asking about programming, do it rather at "Programming" section, please. Starter Kit contains ready to compile and run examples (commented Pascal source code) generally only for beginners (beginners on LE, not in programming...). Most examples are based on official tutorials, so, for full understanding, you should start from these documents and videos: http://www.leadwerks...e2/_/tutorials/ Official tutorials are written with C++, so for fast startup with Pascal, use corresponding code from "LE2 Starter Kit for Delphi and FreePascal". For example: if you analyze "Making a spectator" tutorial, use "MakingASpectator.pas" as Pascal syntax reference for this tutorial. And now, step-by-step instruction how to make simple program in Lazarus for loading scene file created in Editor. 1. Create new folder and copy header files here (LEUtils.pas, LECore.pas, LEObjects.pas). 2. Open Lazarus IDE. 3. Make new project (File->New->Console application), then [Cancel] on creator window. 4. Replace code in source editor window (copy-paste from here): program project1; {$MODE DELPHI} uses LEUtils, LECore, LEObjects; var // Entities lua : Pointer; fw : TFramework; camera : TCamera; // Camera moving and rotation variables camrotation : TVec3; mx, my : Single; move, strafe : Single; begin // Initialization RegisterAbstractPath (''); Graphics(800,600); HideMouse; MoveMouse (GraphicsWidth div 2, GraphicsHeight div 2); // Setup framework fw := CreateFramework; lua := GetLuaState; lua_pushobject(lua,fw); lua_setglobal(lua,'fw'); lua_pop(lua,1); fw.SetHDR(1); fw.SetBloom(1); // Create player camera camera := fw.Main.Camera; camera.SetPosition(-4,2,0); // Load a scene created in editor LoadScene('abstract::tunnels.sbx'); // Startup camera transformation values with camrotation do begin X:=0; Y:=0; Z:=0; end; mx:=0; my:=0; move:=0; strafe:=0; // Main loop while (not AppTerminate) and (KeyHit(KEY_ESCAPE)=0) do begin // Camera mouse look mx:=Curve(MouseX-GraphicsWidth/2,mx,6); my:=Curve(MouseY-GraphicsHeight/2,my,6); MoveMouse (GraphicsWidth div 2, GraphicsHeight div 2); camrotation.x := camrotation.x+my/10; camrotation.y := camrotation.y-mx/10; camera.SetRotation(camrotation); // Camera movement WASD move := Curve(KeyDown(KEY_W)-KeyDown(KEY_S),move,20); strafe := Curve(KeyDown(KEY_D)-KeyDown(KEY_A),strafe,20); camera.Move(Vec3(strafe/10,0,move/10)); // Render by framework fw.Update; fw.Render; Flip; end; end. By the way, no offense, but if you don't understand what these commands do, try start from analyzing tutorials and documentation. 5. Save project in folder created on step 1. 6. Build project (Run->Build or Ctrl+F9). In messages window you should see "Project "project1" successfully built" 7. Copy "project1.exe" file from project folder to your Leadwerks Engine root folder (where Editor.exe and engine.dll exists). 8. Run project1.exe from engine root folder. Now you should see tunnels scene (and you can fly around: mouse + WASD). You could try loading your own scene (instead "tunnels.sbx"). In next step you can extending this project by programming some gameplay. I hope this helps.

Sure. More precisely - you can use any compiler of any language, provided that it is able to use procedural C-DLL's. WChris uses the Delphi Starter Edition with their own VCL components for LE if I remember correctly.

You can also try with my "Starter Kit" package for Delphi and Lazarus / FreePascal. It's ready to use - contains the actual headers and a bit over 20 ready to run simple examples. Each example is a separate *.pas unit. All units are compiled into a single application with project file "LETutorials.dpr". Content is just updated and now is compatible with the latest version LE 2.5. See here: http://www.leadwerks...and-freepascal/ Have fun.

Great! I love to see a new news about 3DWS in LE3D. If I could possibly make a suggestion (of course if this not be a problem) ring torus would be very useful basic (or compound) shape. For example: his severed parts in conjunction with the cylinders are the perfect elements to create pipes and complex pipelines. As we all know, old rusted pipes are very important part of all dark underground tunnels ;-)

Flexman, the usefulness of CSG tools depends on the adopted methodology for the scene design. For example: this is especially handy if we build a prototypes (method of successive approximations). You don't need to work constantly with the artist(s) or using the Max to make improvements on an ongoing basis in scene geometry. Treat CSG geometry as visible representation of a collision meshes. Only when you are sure the scene is well designed (by extensive gameplay testing) - you may give "CSG sketch" as base for implementation of detailed models by the artist in Max or other dedicated tool. The reverse order (I have some nice models and now think of the game for them) rarely leads to success - at least in games where the level design is important for gameplay. But, for example, for flight simulators CSG probably are not useful

I'm not sure if I understand what is a problem. In my view, method of drawing and modifying brushes, faces and vertices exactly like in 3DWS (click and drag) is close to perfection, very intuitive and allowing for really quick "sketch" of geometry. If this interferes with the default editing principles in LE3D editor, you may want to consider two switchable modes: standard and editing of CSG (as Metatron already say). It seems to me that it would be a good option. In any case, I would be little disappointed if the way of CSG editing will be significantly different than in 3DWS.

I hope that something like that would be really possible? Of course 3DS Max is a slight exaggeration , but adding of smoothing (by smoothing groups, or automatic by angle between face normals) and some additional brushes like a ball, a "real" torus (made by revolving a circle), etc. will be very appreciated. Incorporating 3DWS with some extensions into LE3D editor, would make this tool unique in class. How many engines allow you to edit the geometry in the editor? Source, Unreal,... I do not know more. Despite the simplicity, the 3DWS allows you to easy create various non-organic lowpoly models - not only the architecture, as some claim. Here's an example - my chair created entirely with brushes in 3DWS. chair_3dws.zip From a distance does not look bad (as placeholder in game prototype - better than a cube ).

Hello. Making smooth models from 3DWS is relatively simple, provided that you have UU3D. As example this is my pipe model (3dw and gmf): smooth_pipes_from_3dws.zip Below I described in a few steps the way, how I do smoothed models with 3D World Studio 5 and Ultimate Unwrap 3D Export your model from 3D World Studio as DirectX (for example pipe.x). Run Ultimate Unwrap3D and open exported file. - Mark "Flip handedness" on import dialog for correct model orientation. After opening you may optionally remove unnecessary "World" bone from bone tree. Menu: 3D Tools -> Modifiers -> Scene -> Scale - Set scaling amt. to 0.0078125 (if 128 3DWS units == 1 meter) - Set center = Origin - Click Apply, then zoom preview a bit. Menu: 3D Tools -> Weld model - click Apply After welding all edges are smoothed. If our model should have some sharp edges there are two ways to achieve them. You can manually make seams if you want full control of where to sharp edges, or choose the automatic method - in most cases works quite well. I chose the automatic method. Menu: Select -> All Menu: 3D Tools -> AutoSmooth Faces - Set marker by Face normal (optionally you may modify angle, but for me 35 is ok) - Click Ok Save result as for example pipe_smooth.gmf (or other format). That's it. Below is a few screenshots to illustrate the above method. Pipes modelled in 3DWS - generally cylinder after some Slice and Extrude operations (and remove unwanted faces). Phases of processing pipes in UU3D Finally - a comparison of pipe exported directly from 3DWS to GMF and processed in UU3D. I hope this helps. If someone, who writes English correctly, would like to do mini-tutorial with this, I have nothing against it. Cheers, Lupin

I had no intention to offend anybody - just my poor English is not able to express themselves more subtly. Josh seems to be very worry about this accident. This is obviously a sad thing and I just wanted to give him some encouragement.

Josh, I think that you should first of all stop thinking about the past and turn toward the future. It seems to me that it is not worth wasting your valuable time to searching the archives. Probably the biggest pain is the loss of documentation for LE2. The rest is not critical. Asset store files, screens, blogs, posts, etc., many of these things are made by individuals from community, and perhaps some may be (in some cases) restored by their authors (if this will be really needed). I hope, that this minor setback with Werkspace, don't affect your great work with development of Leadwerks Engine (I believe that the engine sources are backed in a better way). Anyway, chill out and don't worry too much.