Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: Jink Engine

  1. #11
    Quote Originally Posted by phibermon View Post
    I don't have ATI hardware except in a laptop and I'm not getting OSX running on an AMD chip any time soon so if anybody out there is running OSX with ATI hardware and would provide testing - I'd appriciate it!
    I would love to try but the last time I tried installing OSX on my computer it field due the fact that I'm also using AMD based CPU and based on information I managed to find on the web OSX suposingly doesn't work on AMD based CPU's. Os if you have any information about how to set up OSX on my computer I'm willing to try.

    Quote Originally Posted by phibermon View Post
    Finally I've looked into Vulkan support and it's well within my grasp - unfortunately Nvidia have refused to support Fermi chips! so no way to test - lets hope ATI have been kinder and supported the chip in my laptop
    Unless this is a newer laptop I wouldn't be so optimistic. Laptop graphics drivers are unfortunately always falling behind especially those from AMD. That is the reason why I have been using unofficial drivers for my laptop graphics card. I did recently revert back to official ones since I'm no longer gaming on laptop and thus I'm more concerned by stability than performance. And unofficial drivers weren't know for rock solid stability.

    Quote Originally Posted by phibermon View Post
    I've massively improved the portal rendering - I'm using it to cheat rendering through windows and the such on my spaceship - from inside or outside
    That is a great idea. I have seen it in several games and I was amazed how good it works.
    Now combine this with a multi-world physics and you can enjoy seeing havoc happening inside the ship when it is hit by a powerful weapon or collides with something.

  2. #12
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    Quote Originally Posted by SilverWarior View Post
    I would love to try but the last time I tried installing OSX on my computer it field due the fact that I'm also using AMD based CPU and based on information I managed to find on the web OSX suposingly doesn't work on AMD based CPU's. Os if you have any information about how to set up OSX on my computer I'm willing to try.
    It is definitely possible but there's a lot of factors - support for your hard disk controller, graphics etc etc - there's some kexts that disable or emulate Intel specific extensions on AMD chips but it doesn't look like a common method, if you make the attempt I recommend aiming for a 'mavericks' install - has the GL4.1 support of later releases but has been out longer so you're more likely to find maverick specific quirks/patches online.

    Quote Originally Posted by SilverWarior View Post
    Unless this is a newer laptop I wouldn't be so optimistic. Laptop graphics drivers are unfortunately always falling behind especially those from AMD. That is the reason why I have been using unofficial drivers for my laptop graphics card. I did recently revert back to official ones since I'm no longer gaming on laptop and thus I'm more concerned by stability than performance. And unofficial drivers weren't know for rock solid stability.
    You're quite right - no Vulkan support from AMD on my hardware - GCN cards only (given the actual chip generations that fall either side of the line at least some of their restrictions are artificial rather than technical limitations of the hardware - but can't really blame them for pushing for newer gear - although 2+ years feels like a con on their part)

    Quote Originally Posted by SilverWarior View Post
    That is a great idea. I have seen it in several games and I was amazed how good it works.
    Now combine this with a multi-world physics and you can enjoy seeing havoc happening inside the ship when it is hit by a powerful weapon or collides with something.
    I'm guessing it's a common approach as it seemed so obvious - I had already worked on culling from one region type into another as my original design allowed regions to be embedded into others (so voxels inside a terrain allowing you to dig into the ground etc) but I thought one day "Well BSP schemes call for totally closed geometry to generate the tree - so I'm going to need some kind of portal if I want to combine them with other regions"

    Then I felt like a total idiot because I was a few steps away from portals for nearly everything - an excellent tool - no engine should be without!

    I'm still having issues with culling from inside voxel regions, IE a random shaped cave mouth with multiple cavities looking out onto a planet. I'm currently using a stencil style approach combined with culling against the viewing frustum but it could be optimized more.

    Games such as space engineers and star-made must have a technique for this but it's hard to find any information - I'm guessing an algorithm that constructs geometry from 'holes' in the voxel chunks that's used for more optimal culling or portal generation.

    I'm guessing it's safe to rule out raster based techniques for constructing portals as we'd be dealing with some expensive image processing that will require a g-buffer to be rendered first.

    camera frustum with a boost from stenciling is ok for now but I have to render things such as tesselated patches at full resolution as it would be too expensive to process the image for each patch to see if it's totally masked off (patches could be heavily deformed by height maps etc) so I only get to discard fragments :\

    EDIT : oh yes sorry! I read up on star citizen how they had external forces applied to objects inside ships and they were raving about what an achievement this was. I mean stop me if I'm wrong but in my setup, I just take the force vector from my ship and apply it to objects 'inside' right? I mean that's around 20 seconds of work - not seeing why they were jumping up and down about it.

    Or I could go one step further and take the ship axis into account or even 'sample' forces at several points and blend the applied force vector between these points for any given object - have some artificial artificial gravity on a ring space station for example.

    Or a blasted hole in the side of the ship could generate forces to 'suck' objects through the hole portal into outer-space - which would be very cool - surely some game already does that by now.
    Last edited by phibermon; 29-09-2016 at 01:04 PM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  3. #13
    Quote Originally Posted by phibermon View Post
    Games such as space engineers and star-made must have a technique for this but it's hard to find any information - I'm guessing an algorithm that constructs geometry from 'holes' in the voxel chunks that's used for more optimal culling or portal generation.
    I guess you probably missed it but Ken Software actually decided to provide access to full source code of Space Engineers
    http://blog.marekrosa.org/2015/05/sp...access_40.html
    http://www.spaceengineersgame.com/mo...urce-code.html

    Quote Originally Posted by phibermon View Post
    EDIT : oh yes sorry! I read up on star citizen how they had external forces applied to objects inside ships and they were raving about what an achievement this was.
    All to increase sales. They weren't the first to use such approach as I have seen it in an older game whose name I can't remember.
    What is strange to me is that such feature is pretty rarely used in space sims.

    Quote Originally Posted by phibermon View Post
    I mean stop me if I'm wrong but in my setup, I just take the force vector from my ship and apply it to objects 'inside' right? I mean that's around 20 seconds of work - not seeing why they were jumping up and down about it.
    Yes that is if you are using your own physics engine. But if you are using some other physics engine which does not support multi-world physics simulation like older versions of PhysX for instance then implementing of something like this can be quite difficult.
    Also you need to consider the fact that inside your ship you would probably want to have much higher precision of physics simulation than for your ship.

    Quote Originally Posted by phibermon View Post
    Or a blasted hole in the side of the ship could generate forces to 'suck' objects through the hole portal into outer-space - which would be very cool - surely some game already does that by now.
    In Space Engineers blasting hole or opening a door of a pressurized compartment will generate force that will push you outward if you are close but nothing dramatic. Not sure if it affects other items (don't play it a lot lately).
    About a year ago I have seen a video of a tech demonstration for a game where opening and airlock could literally such things (characters, furniture, etc) out of it. Unfortunately I don't remember its name. I'm really interested to know about how much progress has been done on it since then.

  4. #14
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    Sorry for the very late reply - went through a messy breakup and did a rocky style training montage.

    Also got into Software Defined Radio and spent a couple of months designing a QPSK demodulator and LRPT decoder for Meteor M2 weather satellite images - that's all in the framework now and tied into the DSP parts of my JAM audio library - so that'll be used by precisely nobody which gives me a warm fuzzy feeling inside.

    Anyway back to the mansion!! the engine sorry - back to the engine.

    I've cleaned up all existing code, ripped out all testing - fixed a majority of compiler warnings etc

    The planet Renderer is working now although development was slowed slightly as I decided to add full GIS style support so I could use what I'd written to create a satellite tracking system + Radio heat map direction finding, then I got lost in adding support for various open source data-sets of street maps - again something that'll be used by nobody - I guess you could make a pokemon Go style thing if you really wanted to.

    Back to procedural generation of planets! I'm using a cube-map style technique combined with a tessellation paradigm to render my planets so along with some 3D perlin noise and GPU based hydraulic erosion - the implementation has been quite a breeze.

    I've expanded upon the Rayleigh/Mie atmospheric scattering implementation I was using for planar terrains to render atmospheres for planets - things are looking really pretty - I'm also playing around with some volumetric shadow and 'godray' techniques to try and get some sexy atmospheric projections of things like clouds and high mountain peaks - efficient and quirk free implementation is very tricky!

    I'm currently brainstorming abstractions for generation parameters for planets - trying to come up with a fairly small set that will give rise to everything from rocky barren moons to lush vegetation filled oceananic worlds - I freely admit that I'm stealing heavily from concepts in 'Spore' here.

    My game will involve a single planet and a couple of moons or maybe a large goldilocks moon orbiting a gas giant (which would look pretty damn epic through the filtered atmosphere) but for the sake of the engine it will of course be logically structured and capable of handling a large procedural universe.

    I'll post some screenshots soon - planets and associated physics are the very last part of the engine to create - I've taken out the low res voxel implementation as mixing it with the other regions is aesthetically weird and for a pure voxel game you're always going to out perform my abstractions by coding for that style directly - one day all engines will be voxels only and it'll make everything in the engine redundant - when that day dawns I'll likely be working on a pure voxel engine.

    Since it's so close to completion I'm now creating a website with documentation, examples, tutorials and all the usual gubbins that will get used be roughly nobody.

    I'll be posting screenshots and videos soon and binary demos soon after that.

    How long have I been working on this and posting about it now? like 8 years here? it's like duke nukem forever but hopefully it'll go down a bit better.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  5. #15
    Quote Originally Posted by phibermon View Post
    I'm currently brainstorming abstractions for generation parameters for planets - trying to come up with a fairly small set that will give rise to everything from rocky barren moons to lush vegetation filled oceananic worlds - I freely admit that I'm stealing heavily from concepts in 'Spore' here.
    Are you generating planets in one go or are you also using some post-processing?
    When I was tinkering around the idea of procedural planet generation I never managed to generate a planet that would have so much diversity as earth does.
    For instance if you go look at our "little blue marble" you can find areas with high peaked mountains and also areas with high but smooth sided mountains. You can find areas with smooth sores areas with cliffed coasts.
    I never managed to convince any of the algorithms that I tried to be able to generate such diversity. I either got all mountains to be spiky or smooth but not both at the same time.

    So I started doing some post-processing to smoothen or roughen different regions. For this I created another texture/height map which would control smoothing/roughing process.
    And it performed quite well. The only problem was that this smoothing/roughing effect was also applied to the regions where it wasn't desired (it could roughen the valleys which would then become all spiky and ugly.

    Because of that I started thinking of doing this post-processing in multiple stages for areas of different elevations. F
    or instance all areas with elevation between 20 and 40 were considered as costal regions (sea level is at 30). All areas with elevation between 40 and 100 were considered as valleys. All regions with elevation between 100 and 150 were considered as hill regions. And all areas with elevation above 150 were considered as mountain regions.
    Now this has been producing much more desirable results but the planet generation time has been increased greatly (even up to 15 minutes). Now this became a little concerning.
    While it wasn't great concern since my plan was to be generating planets in neighboring solar systems in the background during the gameplay and you probably would not be able to reach those neighboring solar system before the planets are already generated (traveling between solar systems would take time - no warping between them).

    Any way in the end I realized that wile my terrain generation algorithm can make very detailed 2D height maps with all the above mentioned variations projecting such height map onto a sphere actually screws up lots of that details especially when you are getting closer to the poles.
    So I put this algorithm of mine aside and started thinking about creating a new one which would be working with spherical coordinates instead of a 2D coordinates from the very beginning. But I never got it implemented as I could not wrap my head around on how to actually make a 3D sphere from these spherical coordinates

    Quote Originally Posted by phibermon View Post
    planets and associated physics are the very last part of the engine to create
    What is your plan for doing planetary physics? Are you planning to implement multi-body physics or will you use SOI (sphere of influence) approach as KSP (Kerbal Space Program) does?

    Quote Originally Posted by phibermon View Post
    Since it's so close to completion I'm now creating a website with documentation, examples, tutorials and all the usual gubbins that will get used be roughly nobody.
    Quote Originally Posted by phibermon View Post
    How long have I been working on this and posting about it now? like 8 years here? it's like duke nukem forever but hopefully it'll go down a bit better.
    Aren't you a bit grim about all this?
    Good things take time to be built. Yes you are working on this project for 8 years which actually isn't so long especially when you take into account that you are basically working on this alone. Even a half dozen sized team of experienced AAA game developers would probably spend at least a couple of years working on similar project.
    So don't be too hard on yourself. Instead be very proud of yourself for this.

  6. #16
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    Quote Originally Posted by SilverWarior View Post
    Are you generating planets in one go or are you also using some post-processing?
    When I was tinkering around the idea of procedural planet generation I never managed to generate a planet that would have so much diversity as earth does.
    For instance if you go look at our "little blue marble" you can find areas with high peaked mountains and also areas with high but smooth sided mountains. You can find areas with smooth sores areas with cliffed coasts.
    I never managed to convince any of the algorithms that I tried to be able to generate such diversity. I either got all mountains to be spiky or smooth but not both at the same time.
    My current design is an attempt to generate successive levels of detail that are deterministic based upon the previous level of detail - this would go hand in hand with mip-map levels in a way and allow for distant planets to be rendered in low detail before moving onto generating the next level of detail.


    In terms of variation of terrain I'm using concepts from the terrain generation tool L3TD - where the lowest level of detail is like a a patchwork of 'biomes' (to use minecraft terminology) which are used at the inputs for detail generation - then to make things more realistic I could have pre-rendered heightmap templates for mountain ridges and the such that are 'stamped' onto the heightmap.


    Then to make the terrain more seemless I was going to use hydraulic and/or thermal erosion passes to blend things together.


    There's lots of problems here of course - even with my GPU implementation of hydraulic erosion I'm very limited in the number of passes I can process on a planetary scale to keep things 'real-time'


    I was thinking one cool hack would be to not process erosion on certain flat plain style areas - perhaps blending the generated heightmap with raster techniques as seen in the impressive lithosphere tool (http://lithosphere.codeflow.org/)


    The key goal here is to not have to rely on generating the entire planet at any given detail level just to see one part of it while still ensuring the end result is identical for any given seed.


    it's really difficult - possible of course but of those systems that do this well already? the developers are not very forthcoming on their approaches.

    Quote Originally Posted by SilverWarior View Post
    What is your plan for doing planetary physics? Are you planning to implement multi-body physics or will you use SOI (sphere of influence) approach as KSP (Kerbal Space Program) does?
    You know I honestly don't know - KSP seems to function well at the large scales but performance isn't great (although I attribute a lot of that to unity) if you've got thoughts on the matter then I welcome them

    Quote Originally Posted by SilverWarior View Post
    Aren't you a bit grim about all this?
    Good things take time to be built. Yes you are working on this project for 8 years which actually isn't so long especially when you take into account that you are basically working on this alone. Even a half dozen sized team of experienced AAA game developers would probably spend at least a couple of years working on similar project.
    So don't be too hard on yourself. Instead be very proud of yourself for this.
    I guess my confidence isn't very high of late - thank you very much for your kind words, they're very much appreciated
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  7. #17
    Quote Originally Posted by phibermon View Post
    My current design is an attempt to generate successive levels of detail that are deterministic based upon the previous level of detail - this would go hand in hand with mip-map levels in a way and allow for distant planets to be rendered in low detail before moving onto generating the next level of detail.
    That was also my goal when I started thinking about creating my own algorithm that would use spherical coordinates and actually store all the data in a tree based fashion. But I haven't got far enough with implementation as I switched to other more pressing ideas like my Silver GUI library that unfortunately hasn't seen any progress for the past six months or my texture making program which needs a major core rewrite in order to allow myself to include few more desired features that can't be implemented at current state.

    Quote Originally Posted by phibermon View Post
    There's lots of problems here of course - even with my GPU implementation of hydraulic erosion I'm very limited in the number of passes I can process on a planetary scale to keep things 'real-time'
    Quote Originally Posted by phibermon View Post
    The key goal here is to not have to rely on generating the entire planet at any given detail level just to see one part of it while still ensuring the end result is identical for any given seed.
    Yes doing things in real time can become quite difficult due to the large amount of processing required. That is why initially I wasn't even thinking about trying it. But my latest design idea is moving in this direction. I figured that until I put this idea into implementation the computer would probably be strong enough for it to work

    Quote Originally Posted by phibermon View Post
    You know I honestly don't know - KSP seems to function well at the large scales but performance isn't great (although I attribute a lot of that to unity) if you've got thoughts on the matter then I welcome them
    The main problem with KSP is that it is using PhysicsX engine in software mode. Why?
    Main problem is that PhysicsX uses single stage physical simulation. What does this means? Since in KSP all ships are made from connected parts physics are calculated in a way that you first calculate new position of root object based on the forces applied to it and then proceed calculating new position for other objects in a tree like manner. This is limiting the processing of any such ship to a single thread. Also until the latest versions KSP only used single world physics simulation (all ships were simulated in a single thread) while in latest version of KSP it is possible to simulate separate ships in separate threads.

    Now it KSP would be perhaps using some different physics engine that uses two stage simulation there would not be so much performance issues. Why?
    Because with two stage physics simulation you use first stage to just calculate new objects position and store that information without moving of those objects right away. Because of this there is no need for your to calculate physics for multiple connected objects in any specific order so you can easily spread the work across multiple threads. And once you have calculated new position for all object you actually move all those objects to their new position but you do this in the second stage.

    So as noted above the main advantage of two stage physical simulation is the ability to spread the work across multiple threads.
    But it does come with its own disadvantages. Main disadvantage is the increased memory requirements as you need to be able to store both old and new position at the same time.
    And the second disadvantage is that second stage also requires some processing time so that the cumulated time to simulate physics and move one part/object to new location is actually higher than in one stage physical simulation. But with clever implementation of double buffering it is possible to reduce that to minimum.

    And even if you could not reduce the additional time needed by the second stage so that processing physics and moving one part/object to new position would take twice as long you could still get almost 50% better overall performance if you can spread all that physics simulation to four separate threads.
    Frankly I'm guite surprised why there aren't many physics engine that actually utilize this two stage physics simulation approach.

    If I would be better at math I would probably try and make Pascal based two stage physics engine but I'm actually pretty bad at math
    But if you are interested I'm prepared to work with you on implementing one provided that you take care about math and I'll try to take care about logical part of implementation

    Quote Originally Posted by phibermon View Post
    I guess my confidence isn't very high of late - thank you very much for your kind words, they're very much appreciated
    That is understandable due to recent events in your life that you mentioned before. But stay strong.

  8. #18
    Quote Originally Posted by phibermon View Post
    Since it's so close to completion I'm now creating a website with documentation, examples, tutorials and all the usual gubbins that will get used be roughly nobody.
    if you don't expect much audience then why not release it already? at least here, for fellow programmers
    tutorials and documentation can be added over time and user feedback can be valuable.

  9. #19
    I say let the man work in peace for as long as he needs to... by the looks of it he's actually onto something worthwhile here! As opposed to, you know, yet another ​horrible useless CPU-killing immediate mode 2D "sprite engine" that really just calls glBegin(GL_QUADS) followed by twenty million or so glVertex2Fs over and over and over again, even though immediate mode has been outdated since the late 90s! Not calling out anyone specific here, it's just a rather unfortunate "trope" of Delphi/Lazarus game engines...

  10. #20
    Yep, keep up the good work!
    Current (and lifetime) project: FAR Colony
    https://www.farcolony.com/

Page 2 of 2 FirstFirst 12

Bookmarks

Posting Permissions

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