Lupin

Thank you for the explanation. Now that I think about it, I wouldn't really want to change this setting for every single texture in the editor. And to do it every time I change something (to keep the graphic style uniform). It would be much more convenient to be able to optionally set some kind of static flag at application startup, maybe SetDefaultTextureFilter(...)? which would be used internally instead of a hard-coded value for each loaded texture. In fact, I don't need to see those pixels in the editor if I could just change the default filtering at game startup so easily. Well, I guess this has turned into a topic for the "suggestion box". Anyway, it's nothing urgent, just wanted to test something.

When I try to change the TextureFilter to Nearest and resave the texture file, I see no effect. Both, the material preview and the scene are rendered as if the linear filtering was hardcoded. Also, when I exit the editor and re-enter, all textures that I changed are set to Linear again. I didn't find any other filtering option in the editor. In pure OpenGL I do something like this: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR ); glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST ); Is this a bug or am I missing something? The effect I'm trying to achieve, visually should look similar to this:

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?