Forum Replies Created

Viewing 15 posts - 91 through 105 (of 125 total)
  • Author
    Posts
  • in reply to: Future development #326
    Sponk
    Keymaster

    Huh? Just pack all textures into one and set the UV coordinates properly. No blending involved.

    https://en.wikipedia.org/wiki/Texture_atlas

    in reply to: Future development #320
    Sponk
    Keymaster

    You can start using atlas textures right now. They don’t need any special support in the engine 😀

    Post about any problem you encounter. Only then it can be fixed 😀

    in reply to: Future development #310
    Sponk
    Keymaster

    Nice video! Well done!

    Your problems with Bandicam are probably about the OpenGL rendering. I don’t know how well 3D applications are supported. Well, it must have worked or else we wouldn’t see this video 😉

    There isn’t really a limit for polygons. The engine is pretty good at throwing polygons to the graphics hardware. The bigger problem is lighting and texture bandwidth i.e. the shading of the polygons. That is very dependent on the hardware used. On some hardware you can have 3 lights with shadows at 1024*1024 resolution without lag. Some hardware barely handles one light with shadows at 512*512. Here you can optimize by using smaller resolutions for example. I noticed that lights without shadows are practically free (at least on my hardware). Could be different on other hardware though.

    Another factor are state changes. That means if you render one object with many different materials instead of packing everything into one image. Some people say it’s about draw-calls. That was right for Windows <= WinXP since all graphics stuff was in the kernel mode and any draw call brought a context switch. You don't have that anymore. Today it's only about state-changes. State-changes are cached and executed when a draw-call occurs. That means that a draw-call is only expensive if you did major state changes like binding another texture etc. You can optimize that by using less materials in your objects for example by using an atlas-texture. Another way of optimizing your graphics are LODs (Level of Detail). This allows you to display a different mesh for each distance of the camera to the object. You can display much lower polygon meshes without loosing visual fidelity this way since far away objects are not as visible anyways. That could be done using a C++ behavior in Neo.

    in reply to: Future development #306
    Sponk
    Keymaster

    The editor currently saves the very first camera you create as the main camera just like the Maratis editor does. You’re right, there should be an option for that.

    The camera clear color is the color which will be used when the screen gets cleared every frame. Think of it as the background color behind all objects. That’s of course only visible if you don’t have a skybox 😀

    Fog works exactly like in Maratis. You enable it and set a distance. And I see I forgot the color chooser to set the right color! Seems like I get a busy day today 😀

    I don’t think that a group should have any visual representation since it is only a construct of thought with no physical effect on the scene. The only thing that I could imagine is a border around all objects it contains when selecting it (like a bounding box) but no object like for cameras or lights.

    I was already working on multi-select in the tree view. One of the problems I got was the synchronization with the right panel. I will see how to fix such issues and upload the changes for you to test 😀

    A tutorial video would be awesome! I’m looking forward to it!
    Btw: Did you notice the new share buttons on each page? Just saying :p

    in reply to: Future development #304
    Sponk
    Keymaster

    Yeah, drag’n’drop works pretty well now. You should definitely use it 🙂

    in reply to: Future development #301
    Sponk
    Keymaster

    Akira_San: I finally got to upload your little tutorial. There were some spelling and grammar mistakes that I corrected. And I added some minor information at some points. I hope that’s ok with you 😀

    You can find it here: http://www.neo-engine.de/wordpress/?wpwtds_article=basic-editor-tutorial
    I still need to include the screen shots though.

    in reply to: Future development #294
    Sponk
    Keymaster

    Hi sadwolf!
    Yes, this feature is on the roadmap and even has an GitHub issue: https://github.com/Sponk/NeoEditor/issues/65

    I think we should introduce bigger features first so they can be tested longer. That means that such smaller things are more likely to be done somewhat later before approaching 1.0 since those features can be done and tested in a few hours while big chunks like an in-game GUI or networking need much more attention.

    I will of course include any patches about such smaller features that are sent to me. It’s just that I have priorities on what to work in my time.

    PS: Finally! More than one participant in here 😀

    in reply to: Future development #276
    Sponk
    Keymaster

    Thanks, I will see how to put it together.

    in reply to: Future development #274
    Sponk
    Keymaster

    From a user interaction perspective. I don’t know how it should behave to be useful. Axis locking might be an idea to start with.

    in reply to: Future development #272
    Sponk
    Keymaster

    Thank you very much! I will upload it to tomorrow.

    The class for a light source is call “MOLight” so I think the right term is not lamp but light. But that’s irrelevant. Everyone knows what you mean by lamp. That’s now problem 😀

    The ortho view is quite experimental. I don’t really know how to do it right.

    in reply to: Future development #269
    Sponk
    Keymaster

    Thank you so much!
    It is already good but I think some more screen-shots would be nice. Imagine you see the editor for the first time and do not know anything about it. You would like to see how it should look like, right?

    Maybe I can make some more screen-shots for showing the different parts of the editor and insert them.
    And I will convert the text to html 😀

    Thank you! That’s exactly what is needed now!

    PS: Do I have permission to use that text on this website? Maybe as a “Creative Commons By” work or similar?

    in reply to: Future development #267
    Sponk
    Keymaster

    Thank you for those links 😀

    in reply to: Questions #266
    Sponk
    Keymaster

    You have to compile the plugin with the Neo SDK header files 😀
    Then everything works (I tried it :p)

    in reply to: Future development #264
    Sponk
    Keymaster

    The asset pack looks very nice. I will see what I can build with it over the weekend :p

    You’re right. We don’t have anything to show off. As soon as 0.4 is ready we’ll have a working web player which we can use to publish smaller demo games. I think that will help a lot to get attention.
    We could also try to get Neo in the ReactOS open source program for extra visibility (it runs perfectly well on ReactOS btw. :D).

    http://community.reactos.org/index.php/support/programs/opensource-development-program *click*

    That would mean that Neo is the only 3D content creation platform that fully supports ReactOS.
    But first we need more to work with. More demos, a smoother user experience and more well tested and documented features.

    Btw: Do you think that you are able to write a small “howto” on using Neo?
    That would be a very huge step in the right direction.

    in reply to: Future development #261
    Sponk
    Keymaster

    Neo already ships with a game engine by default. It is a heavily modified version of the Maratis 3D engine. Which features will land is only dependent on 1) How much time I will have in future and 2) How much contribution happens through a community.

    I can’t promise anything for sure. The project is a just hobby for me right now and the community is very, _very_ small (currently just you :D).

Viewing 15 posts - 91 through 105 (of 125 total)