TTLG|Thief|Bioshock|System Shock|Deus Ex|Mobile
Page 3 of 4 FirstFirst 1234 LastLast
Results 51 to 75 of 77

Thread: FMEditor Project (Update: Devlog #2 - Polygons, Cells and WorldRep)

  1. #51
    New Member
    Registered: Jan 2021
    I was reading the FM stats thread and I saw that people were speculating that FMEditor would bring some fresh blood. Well, The announcement definitely motivated me to begin writing and planning my first FM(s). I'm eagerly waiting for updates on this. Keep up the amazing work guys!

  2. #52
    Member
    Registered: Aug 2009
    Location: Cracow, Poland
    Thank you BazookaBear. Glad we inspired you. We will keep you all updated, so stay tuned!

  3. #53
    Member
    Registered: Aug 2009
    Location: Cracow, Poland
    Hi Folks Our very first developer update is now here!!!

    Book your time, sit down and have a look on our work-in-progress editor in this 0,5h video:



    Waiting for your comments/questions/feedback!

    Konrad (me) & Juliusz (PinkDot)

  4. #54
    New Member
    Registered: Jan 2014
    Looks pretty rad, I gotta say. I never played with DromEd, but I might crack this one open when it's done.
    Reminds me a lot of the old UnrealEd that shipped with Unreal and UT99, but with some more modern features.

  5. #55
    Member
    Registered: Sep 2005
    Location: Prague
    This already looks too great! Looking forward to see how you do portalization and lightmapping passes - you can probably find some inspiration in the gtkradiant project - I remember being able to get the basic CSG concepts from that project when I tried doing a map compiler in perl aeons ago.

    Do you guys have all the remaining data structures mapped out? PHYS chunk? I have some notes still on that if you'd like to have those.

    Btw - Konrad - are you by any chance the dude that approached me a time ago on the openDarkEngine project? His name was also Konrad.

  6. #56
    Member
    Registered: Oct 2004
    Location: Ireland/Poland
    Thanks - portalization and lightmapping is still far ahead - in the first phase we'll rely on Dromed for processing the missions files.

    Do you guys have all the remaining data structures mapped out? PHYS chunk? I have some notes still on that if you'd like to have those.
    Not all of them yet. For the reason mentioned above, physics chunks have not been fully reverse engineered yet. I'd be definitely happy to take any notes you might have!

    Right now I'm finalizing the Objects System - getting every data structure correct down to every single byte is a bit of a pain now - I mean very tedious task. Especially dealing with Thief 1 and 2, where structs have changed, but not the versions of chunks. Very sloppy, LGS - if you read me - very sloppy...

    Btw - Konrad - are you by any chance the dude that approached me a time ago on the openDarkEngine project? His name was also Konrad.
    Not going to answer for Konrad, but I have also approached you millenias ago - back in 2012, I think. I've been asking for WorldRep format, when I was writing my import script for 3dsmax. That kinda slowly started the process, so in a way, you have your contribution to this project, too!
    Last edited by PinkDot; 11th May 2021 at 13:43.

  7. #57
    Member
    Registered: Sep 2005
    Location: Prague
    Quote Originally Posted by PinkDot View Post
    Thanks - portalization and lightmapping is still far ahead - in the first phase we'll rely on Dromed for processing the missions files.


    Not all of them yet. For the reason mentioned above, physics chunks have not been fully reverse engineered yet. I'd be definitely happy to take any notes you might have!
    No problem! You might've already seen this file as it is in the repo, but this should be most of what I was able to decypher https://github.com/volca02/openDarkE...EM/readphs.cpp There's still work to be done, notably around Phys contacts. What further complicates things for you is that this thing is generated not only from the object system, but also from the models - so you'll probably have to implement, at least rudimentary, support of loading BIN files (and probably .CAL files as well).

    Quote Originally Posted by PinkDot View Post

    Right now I'm finalizing the Objects System - getting every data structure correct down to every single byte is a bit of a pain now - I mean very tedious task. Especially dealing with Thief 1 and 2, where structs have changed, but not the versions of chunks. Very sloppy, LGS - if you read me - very sloppy...
    That's not a simple task. Especially some details around ACT/REACT as I remember were problematic.

    Quote Originally Posted by PinkDot View Post
    Not going to answer for Konrad, but I have also approached you millenias ago - back in 2012, I think. I've been asking for WorldRep format, when I was writing my import script for 3dsmax. That kinda slowly started the process, so in a way, you have your contribution to this project, too!
    Oh yes, I remember you! Glad you kept working on projects around Dark Engine.


    I hope at least my WorldRep work finds a way to be useful, but frankly in a few months we can get big parts of the dark engine source code from the NightDive guys (at least that's what has been promised) - so your work should get a tad easier then (but I hope it will spark new projects). Crossing fingers.

  8. #58
    Member
    Registered: Oct 2004
    Location: Ireland/Poland
    Thanks for the link - I'll have a deeper dive into it, when time comes.

    What further complicates things for you is that this thing is generated not only from the object system, but also from the models - so you'll probably have to implement, at least rudimentary, support of loading BIN files (and probably .CAL files as well).
    Ah, yeah - we'll be obviously loading .bin files entirely for the editor anyway, so this should be covered, when it comes to building physics related chunks.

    That's not a simple task. Especially some details around ACT/REACT as I remember were problematic.
    Oh, yes - parts of the structs are dynamic - I had to do some extra gymnastics to get it working. Now my focus is to get all the structs supported from all 3 games and their versions (NewDark or OldDark). This is just very... unattractive part of the project, so to speak.

    I hope at least my WorldRep work finds a way to be useful,
    I had been using your code for .bin mesh loading as well, not just worldrep - very useful!

    but frankly in a few months we can get big parts of the dark engine source code from the NightDive guys (at least that's what has been promised)
    I'm not too familiar - are they releasing source code for SS2? Is it going to be different from the one that got already leaked?

  9. #59
    Member
    Registered: Aug 2009
    Location: Cracow, Poland
    I'm happy to see your reply, Filip

    Quote Originally Posted by Volca View Post
    Btw - Konrad - are you by any chance the dude that approached me a time ago on the openDarkEngine project? His name was also Konrad.
    Yes, It was me

    Quote Originally Posted by Volca View Post
    No problem! You might've already seen this file as it is in the repo, but this should be most of what I was able to decypher https://github.com/volca02/openDarkE...EM/readphs.cpp
    Thanks for sharing this. Personally, I might eventually try to reach you in relatively mid-far future, as soon as I'll be going deeper into mission build process topic. For now, all that keeps me busy is editor GUI and 3D render itself


    Quote Originally Posted by Volca View Post
    but frankly in a few months we can get big parts of the dark engine source code from the NightDive guys (at least that's what has been promised) - so your work should get a tad easier then (but I hope it will spark new projects). Crossing fingers.
    Hmmm. NightDive develop their SS in Unreal Engine. I wasn't aware of the fact this has something to do with original engine being released to public.

  10. #60
    Member
    Registered: Sep 2005
    Location: Prague
    Quote Originally Posted by Marzec View Post
    I'm happy to see your reply, Filip



    Yes, It was me
    Oh how the turn tables!


    Quote Originally Posted by Marzec View Post
    Thanks for sharing this. Personally, I might eventually try to reach you in relatively mid-far future, as soon as I'll be going deeper into mission build process topic. For now, all that keeps me busy is editor GUI and 3D render itself
    No problem, I'm not sure if I still have enough knowledge in my head but I will try returning to the project to gather info for you, should you need my help.

    Quote Originally Posted by Marzec View Post
    Hmmm. NightDive develop their SS in Unreal Engine. I wasn't aware of the fact this has something to do with original engine being released to public.
    Yea NightDive are preparing both SS1 and SS2 releaseses - SS1 is a remake, whereas SS2 is a remaster. They are teasing stuff on twitter constantly, but what I was referencing were messages dropped by Stephen Kick himself, lately they have been active on systemshock.org - he's mentioning the source code release there too.

    I know about the leaked source code, but it is legally a grey area to work with so that is a no-go for an open source project. This would clear things up and open some doors, so I'm hopeful.

  11. #61
    Member
    Registered: Aug 2009
    Location: Cracow, Poland
    Quote Originally Posted by Volca View Post
    Yea NightDive are preparing both SS1 and SS2 releaseses - SS1 is a remake, whereas SS2 is a remaster. They are teasing stuff on twitter constantly, but what I was referencing were messages dropped by Stephen Kick himself, lately they have been active on systemshock.org - he's mentioning the source code release there too.
    What I read on systemshock.org is the following:

    Quote Originally Posted by pripyatbeast
    Anyone who grants Nightdive permission to use their work will be credited in the game and given keys to the Remake and SS2:EE as a thank you. We will also be giving beta access to those who want to try it out and provide feedback.

    When the project is complete we will release the source code on our github
    From what I read I'm not sure if he's talking about "Remake" or "SS2:EE". I thought SS2:EE will only be a collection of mods and improvements/tweaks. Does SS2:EE deal with dark engine source code updates, too? If yes, release of it will be a huge boost to our project, too.

  12. #62
    Member
    Registered: Sep 2005
    Location: Prague
    Yea they do have the source code and are porting it onto the KEX engine. From what I gather the source code release will be of what they got before they made it work on KEX. They are working on improved co-op and also VR support - things they need the source code for. I hope the source code will include Thief parts, it's quite hard to separate those two, in my opinion.

  13. #63
    Member
    Registered: Aug 2009
    Location: Cracow, Poland
    Then the questions are:

    1. Will the new remaster support existing FMs?
    2. If yes, what is the amount of effort to make the FMEditor remaster-compatible.

    Most likely we need to wait until the release to be able to answer all of this.

  14. #64
    Member
    Registered: Jun 2009
    How is this coming along? Very excited

  15. #65
    Member
    Registered: Aug 2009
    Location: Cracow, Poland
    Hi Ascobol. A new video is planned very soon.

  16. #66
    Member
    Registered: Aug 2018
    I am curious what tools Night Dive will release with System Shock: VR.
    Perhaps this all tools along with FMEditor we could use as KEX tools for no more hassle with newdark?

  17. #67
    Member
    Registered: Aug 2009
    Location: Cracow, Poland
    Hey Taffers. 2nd FMEditor video is now available:



    In tonight's episode:

    1. Face properties
    2. N-sided shape brush inspector
    3. Gimbal based rotation gizmo
    4. Symmetry- and center-oriented drawing functions
    5. Polygons, Cells and Solid World display!
    6. WorldRep is now updated after portalization

  18. #68
    Member
    Registered: Jan 2001
    Location: Constantly losing tug o'war
    Some great features there. I like the ability to edit a cylinder's parameters instead of having to rebuild it.

    I know next to nothing about 3d graphics, but have you tried using Dromed's wr_export_obj command to help you translate the miss file data into UV coords? Would it even be feasible for your program to render the .obj file itself and treat it as a layer?

    I have some other suggestions, assuming these aren't already on your list:
    It would be very nice to have something that auto-rotates the texture to match the slope of a wedge brush. This would be especially useful when using beam/trim textures on the outside edges of stairs. This would be applicable for alignment modes 'Norma' and 'Extended'.
    Another useful texture feature, which would help with the above but also be useful in it's own right, would be the ability for us to quickly change rotation by a preset amount, e.g. 45, 90 etc. Some trim textures run vertically, others horizontally, so an auto rotate tool would sometimes be out by 90, or maybe 180 etc.

    Another one - a feature to set the correct sunlight direction for given celestial object. We can have three. Most of us will put the moon/sun in Celestial 1 but it would be wise to let the user choose which one to use, e.g. by putting the button in the dialog box for each of them. It would also be good to always keep them in synch, but that should be an option in case the user is implementing these things in an unconventional way.

    I also think the brush orientation/size fields should show 3 or 4 decimal places, or the user should have the choice.
    Last edited by R Soul; 26th Jun 2021 at 15:16.

  19. #69
    Member
    Registered: Aug 2009
    Location: Cracow, Poland
    Quote Originally Posted by R Soul View Post
    I know next to nothing about 3d graphics, but have you tried using Dromed's wr_export_obj command to help you translate the miss file data into UV coords? Would it even be feasible for your program to render the .obj file itself and treat it as a layer?
    As a matter of fact we did that and it had several downsides:
    1. wr_export_obj creates a very inefficient material collection. Basically almost every wall is another material pass and this is not how you optimize render on GPU level. So if we would like to use it, we would need to parse and fix that.
    2. Having an export, you loose the information of a brush corelated with each wall. Soon, we want to have clickable ability to choose the brush face on the render itself, just like in DromEd. And I think it's probably impossible to do it using the export iself.

    Apart from that the export worked fine and in fact you can see it (with textures hidden) on our teaser video.

    I have some other suggestions, assuming these aren't already on your list:
    Thank you for your feedback. All suggestions make a total sense to me. I will put them on our list.

    To quickly change rotation by a preset amount, you have this round-shaped ui element in top toolbar, for rotation step. It affects the rotation step in degrees globally. So if you rotate a brush with rotation gizmo, it will "snap" to this rotation step "grid". It will work the same when you roll the middle mouse button in rotation text fields on the right side of the window.

    The grid value works the same. Will affect both dragging using gizmo and middle mouse button on text fields.


    I also think the brush orientation/size fields should show 3 or 4 decimal places, or the user should have the choice.
    Yes, you're right DromEd shows 3 decimal places, so we should consider showing 3 or 4, since we have place for it anyway.
    Last edited by Marzec; 27th Jun 2021 at 02:00.

  20. #70
    Member
    Registered: Feb 2021
    This is amazing work. You and your dev team are doing an incredible job with this project. I can't wait to see the finished project, and try it out myself!

  21. #71
    Member
    Registered: Aug 2009
    Location: Cracow, Poland
    Thank you Esse I know you can't wait, but you must Me and my team (again me and PinkDot) are very happy to see your comment

  22. #72
    TomJetland
    Guest
    This is fantastic news! Just restarted playing Thief 2 OM's and stockpiling like 100 Fanmissions. Then, through the 2020 FM stats thread, I found out about your project literally 1 hour ago. I am very excited!

    About 20 years ago I had a good look into DromEd and then decided to DropIt. Too cumbersome for me. When I have something in front of my imaginary eyes (or even from dreams), I want to manifest it as fast and as smoothly as possible, as long as the impression is still fresh. That's when the essence of what I am feeling can be communicated (same with music).

    Once this gets released, I might finally be able to build those levels that are spooking in my head for a long time now!

    What will be the scope of manipulation with Python in the FMEditor? How can knowledge of Python be incorporated in level design?

    Greetings, TJ

  23. #73
    Member
    Registered: Aug 2009
    Location: Cracow, Poland
    Hi Tom. Great to hear that

    What will be the scope of manipulation with Python in the FMEditor? How can knowledge of Python be incorporated in level design?
    FMEditor will expose a Python API. And, similarily to DromEd command line, you will have a Python Console with a direct access to current editor objects and their APIs. This is still an early design idea, so that's all I can say.

  24. #74
    Member
    Registered: Oct 2004
    Location: Ireland/Poland
    Quote Originally Posted by TomJetland View Post
    What will be the scope of manipulation with Python in the FMEditor? How can knowledge of Python be incorporated in level design?
    Hi Tom,
    I come from 3D animation backgrounds and have experience with such software as Maya or 3dsmax. In there, you have embedded Python editor, which allows you to execute any commands and query/edit any aspect of the scene interactively or run any Python script.
    You can also build your own tools with GUI (dialogs), which can be integrated with the editor's GUI (e.g. adding menu and menu items). You can change applications' settings.
    You can set up a start up script to execute certain commands or set up an environment for larger pipelines.
    You can do some file I/O operations like loading and saving scenes and interact with operating system as well, etc...
    Finally, you can share the scripts with others, so they can enjoy the same tools that you wrote.

    I'd like to have the same for FMEditor.

    This way you could write anything from simple scripts like 'set the texture of bottom face of all (or selected) cylinders to specific ID' to 'pre-release QC Checks of a mission' to creating your own fully procedural levels.
    Up to you.
    Last edited by PinkDot; 5th Jul 2021 at 17:23.

  25. #75
    Member
    Registered: Sep 1999
    Location: Texas, hhhwweeee hawww
    Wow, was away and it this community always surprises me when return. This is very exciting and will help immensely in certain areas of my mission! Thank you guys for working on this!

    I do have one concern though; I haven't seen all the videos but on the first video, I saw moving chunks of brushes together, and even rotating a circle of window-sized brushes in place. Since this uses Dromed underneath, is this independent instructions to the brushes, or is it utilizing multibrushes? I hope they are purely using independent commands on each brush.

    I worry about that micro fracturing issue as I call it, whereby if you move several brushes together as a multibrush group it doesn't actually care to snap to the grid correctly. Even if the brushes within the group were snapped and perfect distances from each other to start with, moving as a multibrush breaks them. You go and look afterward and see it snapped on .000004 of the grid. It would cause Portalization errors and the "find unsnapped" command cannot see such small values they're off by.

    The way around this was to move the multibrush and then after closing group, "tease" each brush with a mouse move, to assure snapping into place.

    Then, a wishlist item is for this editor to auto generate room brushes to fill out a detected air brush path, to help fill out odd shaped places all while not bleeding into near by room. Like how people have to create tessellating room brushes up ramps or in roofs. Perhaps only within an area you would first highlight before generating, so it doesn't unnecessarily room brush your whole mission.

    Thanks!

Page 3 of 4 FirstFirst 1234 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •