Русский New site

Advanced search

[ New messages · Forum rules · Members ]
Page 21 of 69«1219202122236869»
Forum » SpaceEngine » Feedback and Suggestions » General suggestions (Post your suggestions here.)
General suggestions
GabeDate: Saturday, 12.07.2014, 19:57 | Message # 301
Astronaut
Group: Users
Canada
Messages: 42
Status: Offline
But wouldn't that work for cataloged galaxies only?




Commander Shepard of the SSV Normandy, reporting for duty.
 
n0b0dyDate: Wednesday, 16.07.2014, 11:53 | Message # 302
Explorer
Group: Users
Pirate
Messages: 297
Status: Offline
I wonder how they manage to create so very detailed asteroid field in ring structure of a planet in Elite: Dangerous :


If you step to around 19:27 and beyond you will see very detailed asteroid field that ring is composed off. Will this be possible in SE? cry


Edited by n0b0dy - Wednesday, 16.07.2014, 11:57
 
ProteusDate: Saturday, 19.07.2014, 04:01 | Message # 303
Explorer
Group: Users
United States
Messages: 172
Status: Offline
Apologies if any of these suggestions have already been mentioned, but they came to mind while I was playing earlier and didn't want to forget them so I'm jotting them down here...

- In Free Mode: Option to switch between toggle movements (for one or multiple directions) and hold-key movements, so we don't have to hold W to go for example, and can instead "engage" it and control other flight perameters separately - basically like aircraft mode but without intertia.

- Space dust or some other more reasonable/logical visual effect for indication of movement through space where it is difficult to see otherwise

- Distance indication/other information (attached to body selection cursor) to have quick, essential information in centered view

- Ability to toggle an option for automatic speed adjustment threshold/limit based on distance to targeted object for prevention of overshoot and smoother arrival during manual flight (adjustable by user?)

- Ability to toggle the top left HUD info (body/object selection information) in particular, separate from the entire HUD

- Image of selected body displaying in lower corner of screen for quick reference during travel (possibly with slow rotation animation?) and simple information on it

- Image of closest body displaying in opposite lower corner of screen for quick reference during travel (only displays when separate body is selected) - good for when traveling on a planet but having a different body selected

- General HUD Facelift to present a somewhat more sci-fi feel to honor the immersive experience a bit more? (see Elite: Dangerous for example) (nothing particularly fancy, just a re-arrangement/panel generation of what currently shows)

- Instead of the 4 arrows around a selection, maybe a glowing circle or something else of a somewhat more upgraded and sci-fi feel

- Set the "look around" function to a key along side the mouse wheel button (and optimize it for better performance)

- Display the ETA to selected object based on current speed during manual flight (and/or during more developed versions of auto-pilot in the future?)

- Ability to toggle lock destination (so that we can click on other systems, etc, while we travel to a desired body and not lose site or focus of our intended destination)







Edited by Proteus - Sunday, 20.07.2014, 09:01
 
Billy_MayesDate: Sunday, 20.07.2014, 10:29 | Message # 304
Pioneer
Group: Users
Finland
Messages: 485
Status: Offline
Quote Proteus ()
- Image of selected body displaying in lower corner of screen for quick reference during travel (possibly with slow rotation animation?) and simple information on it


Quote Proteus ()
- General HUD Facelift to present a somewhat more sci-fi feel to honor the immersive experience a bit more? (see Elite: Dangerous for example) (nothing particularly fancy, just a re-arrangement/panel generation of what currently shows)


Quote Proteus ()
- Instead of the 4 arrows around a selection, maybe a glowing circle or something else of a somewhat more upgraded and sci-fi feel


Quote Proteus ()
- Display the ETA to selected object based on current speed during manual flight (and/or during more developed versions of auto-pilot in the future?)


These all seem to be great for the future MMO, but would have to be optional for people with slow computers, since for example the rotating planet in the HUD would have to load too in addition to the actual planet. It would also be great to customize and move the HUD around. But good ideas, Proteus.





AMD Phenom II X4 955 3.2 GHz Quad-Core - AMD Radeon HD 6950 2GB VRAM - 4GB RAM - 1680x1050 75 Hz Samsung screen
 
CyriousDate: Monday, 21.07.2014, 02:18 | Message # 305
Observer
Group: Newbies
United States
Messages: 1
Status: Offline
Hey there, new person posting here :D

So, couple days back I had gotten to thinking about possible upgrades/improvements to the software, and this all ultimately started from shortly after the release of .971 and watching a planet surface render at LOD bias 2. I noticed that while rendering, it did each "chunk" or square of the planet's surface one a a time, sweeping from side to side and working its way further out away from the camera.
The big thing that I noticed though was that the processing of each segment was done one after another, and my system monitoring doesnt note any change in CPU useage and minimal change (15% increase) in GPU useage when the rendering is in progress.

Now, my CPU is pretty powerful when compared to most other CPUs on the market (how can it not be? its a freaking 8-core LGA 2011 Xeon), but while space engine is running and doing its thing, its only using 2 cores. The only time I've seen it use more than two is when I get bored and make a superluminal dash through a galaxy, at which point the game attempting to keep up starts sucking up the other threads like they're made of candy.

So i get to thinking: Why not allow LOD processing access to another thread/CPU to speed things up? Nearly half of all computer users these days have at least 4 cores/threads to use, and throwing another thread at the rendering could make moving around on a planet's surface at a high detail setting less punishing.

Then I start to think of other things can could be helped with offloading from the main threads to "slave threads" to speed things up a bit. The (admittedly) small list is below, along with my reasoning:

Multithreading the LOD landscape processing:
I've already explained this one, but just to recap, the idea is to spin off another thread or two when beginning the processing to allow for more area to be sharpened at once. This is so that when a player is on/near a planet's surface, moving around doesnt punish them so much.

Multithreading/GPU rendering atmospheric halos (if implemented):
I saw the forum post regarding atmospheric halos, and i figured alot of simple raytracing that would be required for such halos could benefit hugely from multithreading. I did a quick benchmark of my CPU using halosim (sundog and sun pillar preset, 16M rays) and using one core, my CPU pulled an average of ~76,000 rays calculated per second. If Halosim was properly multithreaded and using all cores, I'd be seeing figures approaching half a million per second. Assuming spaceengine gets a proper basic raytracer for generating atmospheric halos and renders on 2-4 threads, it could render a quarter million rays in under a second, ample to form most of a halo. If offloaded to the GPU, some of which can have thousands of individual shader cores, rendering the atmospheric halo could be done near instantly. Add in all of the modern instruction sets that exist, and the processing time could be cut even further.
Basically, the raytracing needed to cook up an atmospheric halo is one of those problems that logic dictates *should* scale extremely well with increasing core/thread/shader core count.

Multithreading of atmospheric simulation:
This is another one that could benefit, at least in larger timescale simulation (days to years). If a dynamic ever changing atmospheric model is to be implemented, throwing at least one more thread at it could allow for splitting the work of simulating an entire atmosphere. This could however maybe get away with running on a single thread until the scale its working on gets too fine grained.

Now, there may be other things in space engine that could benefit from hurling more threads at the issue, either now or in the future, but if there are I cannot think of them at this time. I also might be just a tad bit biased in terms of multi threading capability simply because of what my CPU is, but people have to keep in mind that the trend so far coming from CPU manufacturers, the consoles, and computing in general is to duplicate hardware and throw more cores at the problem to speed things up. I figured that since space engine is still being worked on, now would be a good time to make it more multithreaded outside of what is done when blasting through a starfield at extreme speed.

I also have some other ideas to add that could be useful, either for the sim itself or for features that users could make use of.

The big one is a benchmarking mode, either triggered via the console or as a menu item, and should include these items:

Generation of a 250 million star galaxy from the procedural algorithms used in the game (stars are limited to anything yellow dwarf or larger. There are far too many red/orange dwarf stars for this. Nothing else is generated, such as planets, nebulae, clusters, anything else). Scoring is done in time in seconds (up to three digits past the decimal for precision), or with points on an inverse logarithmic scale (the lower the time it takes, the higher the score). Test should be both single and multi-threaded.

Rendering the entire surfaces of several worlds from scratch according to the algorithms used in game. Each world is rendered one at a time with the polygon count of each planet going up as the benchmark progresses. Score is given both in time to completion, and polygons per second.

Basic moderate accuracy simulation of 2 galaxies colliding, stars only (10-20k stars per galaxy). The test is either multi-threaded or uses the GPUs to process it. Scoring is in frames per second, and runs until the gravitational center of both galaxies is determined to have completely merged, or five minutes have elapsed real time, which ever is first. I got the idea for this one from a Linux screensaver that did basic simulations of up to 5 galaxies colliding. It didnt use up much CPU power and was kinda neat, and I wonder how space engine would handle it later on once implemented.

The benchmarks obviously cannot be added now as there is a number of things that have to be added to the game in the first place (good and proper multi-core support being the big one), but after release I'd like to see these added for the benchers among us.

So, what do you guys think? Am i out of my freaking mind or are some of these good ideas?
 
SpaceEngineerDate: Monday, 21.07.2014, 13:15 | Message # 306
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4796
Status: Offline
Quote Cyrious ()
So i get to thinking: Why not allow LOD processing access to another thread/CPU to speed things up? Nearly half of all computer users these days have at least 4 cores/threads to use, and throwing another thread at the rendering could make moving around on a planet's surface at a high detail setting less punishing.


SpaceEngine uses GPU, not CPU, to generate terrain textures and height maps. Also, OpenGL can't easily render in multiple threads (it is diffucult to acheive), and it have no sense, because you have a single GPU and it is already highly parallel system (hundreds of single shader processors). And no, SLI/CrossFire is not like multiple cores, it is like additional shader processors for the main GPU, what may only render the same thing that main GPU do.

Raytracing on CPU? GPU still benefits there, even if you have 8 core CPU. And take into account what many players have mid-spec PCs... So I think implementing such complex thing is in the very far todo list. There are a lot of more important things.

Atmospheric scattering has nothing to do with CPU too. It is just a shader effect what uses precomputed textures. It is possible to move precomputation on the CPU, but it have no purpose. Seasonal changes can be implemented by changing density/opacity parameter in the rendering shader. More complex and realistic model would needed to re-compute the scattering textures, but again, it will be much faster on GPU.

SpaceEngine uses multithreading in various places: generation of galaxies, stars and planetary systems (try run the search in the Star Browser and look at your CPU load), and loading textures and models from the disk. Generation of the terrain textures is done completely on GPU. But don't worry, there are a lot of work what CPU cores will do in the future: physics, networking, AI...

Quote Cyrious ()
The big one is a benchmarking mode, either triggered via the console or as a menu item, and should include these items:

LOL, SpaceEngine already have the 'benchmark' console command smile It enable time measurement of textures generation/loading, and print it in the log. You may also measure the time of the complete generation of the planet surface from the current point of view. Land on a planet, go to Debug mode, and press Ctrl-F5. The planet will reload, and the time will be printed in the log.





 
pzampellaDate: Friday, 25.07.2014, 19:57 | Message # 307
Space Pilot
Group: Users
Venezuela
Messages: 115
Status: Offline
Maybe this suggestion has already been made, but this is a really long thread to read it entirely! I understand that collisions will be implemented in the future. However, there are objects like comet ISON that still exists in SE even if it was destroyed by the sun. I would be great for some asteroids and comets that when they disappear, the object no longer exists in the future.
For example, ISON was destroy on Nov 27, 2013. If you search for it before that date, you can see it. But if you search it later, you won't be able to find it.
Explosion and collision's can wait, but the existence of an object must be easy to modify. Thx!
 
IdgeliosDate: Saturday, 26.07.2014, 01:04 | Message # 308
Astronaut
Group: Users
United States
Messages: 77
Status: Offline
I'd love to see a feature where you can edit in-game wiki information. Currently you can rename planets, but despite the wiki box appearing in edit mode and the box even highlighting it doesn't seem like you can edit it in-game.
 
RockoRocksDate: Saturday, 26.07.2014, 08:03 | Message # 309
World Builder
Group: Users
Belgium
Messages: 673
Status: Offline
Quote Idgelios ()
I'd love to see a feature where you can edit in-game wiki information. Currently you can rename planets, but despite the wiki box appearing in edit mode and the box even highlighting it doesn't seem like you can edit it in-game.

SpaceEngineer already has plans to do this, look at the bottom of this blog post.





I will be inactive on this forum for the time being. Might come back eventually

AMD AR-3305M APU w/ Radeon HD 1.90 GHz 6,00 GB RAM
 
DeathStarDate: Saturday, 26.07.2014, 16:36 | Message # 310
Pioneer
Group: Users
Croatia
Messages: 515
Status: Offline
I think that SE should have it‘s own official wiki. This wiki should document the various types of celestial bodies in the game, and later on the gameplay mechanics. There should be articles on, for example, oceanias, gas giants, asteroids, brown dwarfs, supernova remnants, spiral galaxies, cosmic structure(filaments, voids) etc.
 
pzampellaDate: Wednesday, 06.08.2014, 16:23 | Message # 311
Space Pilot
Group: Users
Venezuela
Messages: 115
Status: Offline
I've been trying to find a thread about this issue, but I haven't found it. The current system to name exoplanets consist (as almost everybody here knows) in adding a lowercase letter to the name of the parent star, starting with "b". But, in SE the procedural exoplanets of real stars aren't named by this system, instead they are named with a number after the parent star's name (example: Taygeta 3 instead of Taygeta c, a procedural planet of a real star in the Pleiades). Is this made on purpose or should be fixed on a new realease?

PD: I actually don't like the exoplanet naming system. I think it would be a lot better (and cool) to add a roman number to name them (like Taygeta III), but I don't think the astronomic community will listen to me! wacko
 
DeathStarDate: Wednesday, 06.08.2014, 17:35 | Message # 312
Pioneer
Group: Users
Croatia
Messages: 515
Status: Offline
The problem would most likely be that it would be hard to distinguish between real and procedural exoplanets if both had the same naming system.
 
pzampellaDate: Wednesday, 06.08.2014, 17:46 | Message # 313
Space Pilot
Group: Users
Venezuela
Messages: 115
Status: Offline
DeathStar, yes and no, because you could turn on and off the generation of procedural planets and find out if it's real or not. But if it was done with that intention, I'll counter-propose to use roman numbers instead =D
 
SpaceEngineerDate: Thursday, 07.08.2014, 13:51 | Message # 314
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4796
Status: Offline
pzampella, in real astronomy planets got their names by order of discovery. Taygeta c don't mean it is the second planet of Taygeta, this mean it is a second discovered planet. Planets may also be unconfirned and removed from the catalog. Although I don't like current naming system too (especially very weird starting from the letter 'b'), but designing a new system have no sense at this time. It will have sense only when we be able to discover all planets of a star, and assign them numbers or letters according to their distance from the star.




 
pzampellaDate: Thursday, 07.08.2014, 14:51 | Message # 315
Space Pilot
Group: Users
Venezuela
Messages: 115
Status: Offline
SpaceEngineer, yes, I understand that. I am just talking about procedural planet's names. In those cases, they are systematically named with numbers instead of letters. I wanted to know if it was made on purpose. I just use Taygeta 3 as an example.
 
Forum » SpaceEngine » Feedback and Suggestions » General suggestions (Post your suggestions here.)
Page 21 of 69«1219202122236869»
Search: