ENG New site

Advanced search

[ New messages · Forum rules · Members ]
Forum » SpaceEngine » Archive » Work progress and public beta test - 0.9.7.4
Work progress and public beta test - 0.9.7.4
x264fhdbenchmarkDate: Thursday, 07.04.2016, 11:39 | Message # 2101
Observer
Group: Users
Pirate
Messages: 17
Status: Offline
Quote HarbingerDawn ()
Of course it would be nice, but that doesn't mean it would be easy to implement.

Really? Scaling texture according to occlusion factor and moving spawn point is that difficult? I'm sure author has done much more complicated coding in his life than my suggestion wink
 
HarbingerDawnDate: Thursday, 07.04.2016, 11:43 | Message # 2102
Cosmic Curator
Group: Administrators
United States
Messages: 8717
Status: Offline
Quote x264fhdbenchmark ()
I'm sure author has done much more complicated coding in his life than my suggestion

It's not about that, it's about how much time is required to implement it vs how important it is. I'm sure he'll get around to it at some point, but I wouldn't expect it to be tomorrow.





All forum users, please read this!
My SE mods and addons
Phenom II X6 1090T 3.2 GHz, 16 GB DDR3 RAM, GTX 970 3584 MB VRAM
 
SpaceEngineerDate: Thursday, 07.04.2016, 11:53 | Message # 2103
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4800
Status: Offline
Quote Irigi ()
I would like to share a behaviour I think is a bug. It is shown on this video. I selected a planet in a star system as a target for hyperjump autopilot. From bigger distance, it worked nicely, but closer, the autopilot seems to be stuck and unable to direct the ship towards the planet. Please let me know if you need additional info. (Save file, perhaps?) Or is this an intented behavior? (Warp field cannot be used closer than certain distance?)


This is because your absolute speed is just 100 m/s. Planet is moving, and quickly goes away from the direction of warp. So autopilot stop warping and corrects the speed vector. Try to use bigger initial velocity.

Quote Irigi ()
At this opportunity, I would like to ask you about the physics of the warping in current version. I understand that the warp field (Alcubierre bubble?) enhances the velocity by certain warp factor. At the beginning of the maneuver, the autopilot changes direction of the velocity towards the target. The velocity seems to always be 10 km/s, only the direction changes. Am I correct, or have I misunderstood anything?

Yes, you are correct.

Quote Irigi ()
And if I am right, relative to what object is this velocity measured?

Relative to global cosmological reference frame (reference frame, where dipole anisotropy of the CMBR (cosmic microwave background radiation) is zero). But for now, galaxies and stars in SE do not moving, so their velocity relative to this reference frame (and relative to each other) are zero. In future, I'ii add stars velocity, and using warp drive will be much more complex (Sun's velocity relative CMBR is 370 km/s).

Quote x264fhdbenchmark ()
Two things are still annoying in latest version.
1) You can see what is below surface of the planet

I see you have some weird issue with the planet in the sky. Do you have updated AND drivers? It seems SE don't use reversed depth buffer - this is why you see through the terrain. Can you send a log file?
I moved ClipHeight to main.cfg, it will changed to 0.01 for Intel automatically.

Quote x264fhdbenchmark ()
2) RivaTuner OSD is being constantly moved off screen during "loading"

Sorry, this is not my problem smile Report this bug to RivaTuner manufacturer :)

Quote galenmacil ()
1.9.7.4 RC2 installed without any issue on Windows 10 64 bit. Did some exploration and the engine seems to behave correctly. No weird slow down or glitches so far.

Thanks!

Quote galenmacil ()
Just a side note: Running in 2xSLI mode cause stuttering and skipping. Performance scale negatively with 2xGTX 980... I suppose SLI is not supported officially?

I also have "negative improvement" with 2 x GTX 780. OpenGL don't like multithreading with shared contexts (what used in SE), and SLI don't like OpenGL. Making engine compatible with SLI is not easy even on DirectX. I will work on it in future, first step will be getting rid of shared contexts.
But at lease SE works in SLI without artefacts smile Unlike AMD Corssfire.





 
SpaceEngineerDate: Thursday, 07.04.2016, 12:04 | Message # 2104
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4800
Status: Offline
Quote Heumarkt ()
On my new system (i7 skylake, 16 GB DDR4, Win7 64) I turned off the windows page file to increase performance and prolong SSD life (a SSD can only handle so much write operations within its lifetime). So far so good. 99% of the programs don't have any problem with that. Unfortunately SE seems to be in the 1%.

It's not safe to completely disable page file in Windows, even if you have 32 GB of RAM. Better to move it on HDD, if you want to save SSD.

Quote x264fhdbenchmark ()
Really? Scaling texture according to occlusion factor and moving spawn point is that difficult? I'm sure author has done much more complicated coding in his life than my suggestion

Yes this is not easy. It's easy for the edges of the screen, but if star is occluded by a planet? It could be occluded by parts of the ship from two sides. How ever you can know where is occluder relative to a star?
The better way to solve this is implementing another algorithm for lens flares. This will be in future.





 
x264fhdbenchmarkDate: Thursday, 07.04.2016, 12:28 | Message # 2105
Observer
Group: Users
Pirate
Messages: 17
Status: Offline
Quote SpaceEngineer ()
I see you have some weird issue with the planet in the sky. Do you have updated AND drivers? It seems SE don't use reversed depth buffer - this is why you see through the terrain. Can you send a log file?
I moved ClipHeight to main.cfg, it will changed to 0.01 for Intel automatically.


here you go
http://paste.ofcode.org/38Kr55T5fyZJSfkubv4hYLu

yes earth like planets have been always like this on this gpu. Yes I have latest drivers. I guess my ancient GPU does not support some extensions :(


Edited by x264fhdbenchmark - Thursday, 07.04.2016, 12:41
 
FireintheholeDate: Thursday, 07.04.2016, 15:01 | Message # 2106
Pioneer
Group: Translators
Sweden
Messages: 356
Status: Offline
Quote HarbingerDawn ()
Of course it would be nice, but that doesn't mean it would be easy to implement.

It's already present in the simple mode of lens flares.





Love SpaceEngine!
 
n0b0dyDate: Thursday, 07.04.2016, 15:53 | Message # 2107
Explorer
Group: Users
Pirate
Messages: 297
Status: Offline
Quote SpaceEngineer ()
Read it again:


I did. But I couldn't believe it until I tried and saw it with my own eyes :p

Quote SpaceEngineer ()
No, modification of the default model is unsupported. Reason is simple - mod must not change generated universe, otherwise we will have a problem in a future online game. Mod may change only visual appearance of a galaxy, but not it's content (ie generated stars). So you may only create a new model. For example, make s script addons/models/galaxies/NewMilkyWay.cfg:

Code

GalaxyModel "MilkyWay2"
{
UseForObject "Milky Way"

FrontTexture "MilkyWay2.*"
FrontImage "MilkyWay2_small.*"

........ other parameters here ........
}

This will replace Milky way model to your new model. If you add UseForType "SBb", new model will be used for some other SBb galaxies (with have no custom model). but if you also add a custom sys texture (for example SysTexture "MilkyWay2_sys.*"), this will change procedural stars in the Milky way and other SBb galaxies, which will lead to changing saved location in MilkyWay and that galaxies and impossibility to share them with other users.



Ok I understand that. I was not asking exactly that. I am not messing with original /data/model.cfg nor I intend to. All I was saying was if I can *only* include the galaxy/nebula parameters that I actually want to change in the addons/model.cfg without *repeatting* the same data of the remaining galaxies/nebulae in the file in order to easyily keep track of the changes I make smile .

Basically I intend to modify all galaxies models inside model.cfg and make all gallaxies dust sprites a bit darker similar to what DoctorofSpace has done for the Milky Way in his addon section. I am not going to change any other parameters nor use another sys texture. So my question is:

- if I *only* change the abs/em parameters in the corresponding section of galaxy model.cfg for *every* galaxy model entry in order to make them a bit darker, will this affect the star seed of every star in every galaxy?

If the answer to this question is yes then I will not do it. I do not want to change the seed.

But I would like to suggest making DoctorofSpace's Milky Way model default for the official SE release as well adapting this model for other galaxies . I find current look of galaxies from inside of them too bright smile . And I know I can reduce the brightness with F7 magnitude/brightness settings menu but this also affects how they look from far / outside.

Obviously I am not talking about copy-pasting DoctosofSpace's Milky Way's parameters all over the remaining entries wink
I will try to dereve a formula from the difference between original and modified parameters of Milky Way and apply proportionall difference to the remaining galaxies.


Edited by n0b0dy - Thursday, 07.04.2016, 16:10
 
Player1Date: Thursday, 07.04.2016, 15:56 | Message # 2108
Astronaut
Group: Users
Mexico
Messages: 49
Status: Offline
I don't like at all the new look of Ankaa 9. In 0.972 it was a template Terra, without moons
Now it has a moon, but it's scorched because tidal heating (I saw the codes and it's true) burning at 827 ºC :(



And I have a question: What does that squares and circles mean at the orbits? The only thing I know is it helps to edit orbits, and nothing else

Attachments: 5862742.jpg(123.7 Kb)





"We used to look up at the sky and wonder at our place in the stars, now we just look down and worry about our place in the dirt"
-Joseph Cooper, "Interstellar"


Edited by Player1 - Thursday, 07.04.2016, 15:59
 
SpaceEngineerDate: Thursday, 07.04.2016, 16:03 | Message # 2109
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4800
Status: Offline
Quote x264fhdbenchmark ()
here you go
http://paste.ofcode.org/38Kr55T5fyZJSfkubv4hYLu
yes earth like planets have been always like this on this gpu. Yes I have latest drivers. I guess my ancient GPU does not support some extensions :(

It also have strange driver version:
Driver version: Context

Quote Fireinthehole ()
It's already present in the simple mode of lens flares.

No, simple mode uses analytic approximation of the planet shape, ie sphere:) So it didn't work correctly with the terrain.
"Super" mode, which can be enabled in console (set LensFlaresMode 2), takes into account shape of the (partially occluded) sun, but it doesn't work good.

Quote n0b0dy ()
Ok I understand that. I was not asking exactly that. I am not messing with original /data/model.cfg nor I intend to. All I was saying was if I can *only* include the galaxy/nebula parameters that I actually want to change in the addons/model.cfg without *repeatting* the same data of the remaining galaxies/nebulae in the file in order to easyily keep track of the changes I make .

No, you can't. SE will use your galaxy/model script as a new model. But if it have the same name as some of the default models, unexpected bugs may occur. And of course the script for a model must be complete, ie have all fields.

Quote n0b0dy ()
I find current look of galaxies from inside of them too bright

Because they are indeed relatively bright, if your planet is not located in the outer spiral arms, like Earth.





 
DocasmanDate: Thursday, 07.04.2016, 16:05 | Message # 2110
Observer
Group: Users
Portugal
Messages: 12
Status: Offline
Quote Heumarkt ()
I turned off the windows page file to increase performance and prolong SSD life


As SpaceEngineer said, you should have some sort of pagefile. If you only have one drive, my suggestion is to create a ramdrive and place a minimal pagefile there (mine is 16 MB). To further spare your SSD from heavy use you can change the TEMP system variable and browser caches to point to the ramdrive (this may have some caveats).
 
MosfetDate: Thursday, 07.04.2016, 16:28 | Message # 2111
World Builder
Group: Users
Italy
Messages: 754
Status: Offline
Player1, those circles and squares are marking the Pericenter and Apocenter of the orbit, or its nearer and further points.
Specially useful when you actually try to achieve a stable orbit.





"Time is illusion. Lunchtime doubly so."
Douglas N. Adams
My mods
Asus x555ub: cpu i5-6200u - ram 4gb - gpu nvidia geforce 940m 2gb vram
 
eatthepathDate: Thursday, 07.04.2016, 16:47 | Message # 2112
Observer
Group: Users
Pirate
Messages: 15
Status: Offline
Quote SpaceEngineer ()
Quote eatthepath ()
Regarding the new addon system: I'd like to be able to remove essentially all catalog objects except galaxies, to make way for a customized fictional galaxy. I script with remove lines for every star in the stock files isn't really practical, is there a recommended way to achieve this under the new system?

LOL what a strange idea. I don't thing there will be many people who want to install such "addon".
There is indeed only one way to do this with addon system - write a huge script with Remove command for each star. I didn't expect what anyone will need such function :)
There is another way - via patch system. Make a pak file, which contains empty files with the same names as default - stars/HIPPARCOS.csv, stars/Stars-bin.sc, etc. Put this file into data/catalogs, and Se will load files from this pak instead of Catalogs0974.pak. But files are empty, so it will load nothing.


Alright, that's about what I thought I'd have to do, and have been doing so far. It's not really an add-on I expect to get a lot of uses, it's mostly for myself and one friend. Gives a bit more control in producing desired skyboxes and such, placing things in distant galaxies is problematic in the current system.
 
SpaceEngineerDate: Thursday, 07.04.2016, 16:53 | Message # 2113
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4800
Status: Offline
Quote the_nerervarine ()
Speaking of finding stars that are way to large I found this procedural Brown Dwarf that is 6 solar radii. (I've seen rather large brown dwarfs like this before but this is the first one I found that was not orbiting a black hole in a cluster or galactic center)
https://scontent.fsnc1-1.fna.fbcdn.net/hphotos....1_o.jpg

LOL it's 6 diameters of Earth.





 
HarbingerDawnDate: Thursday, 07.04.2016, 16:56 | Message # 2114
Cosmic Curator
Group: Administrators
United States
Messages: 8717
Status: Offline
Quote SpaceEngineer ()
Because they are indeed relatively bright, if your planet is not located in the outer spiral arms, like Earth.

He means the galaxy sprites are rendered too brightly when the galaxy is viewed from inside, compared to the default magnitude limit, and I agree. 3.0 would be a much more realistic value than 4.0.





All forum users, please read this!
My SE mods and addons
Phenom II X6 1090T 3.2 GHz, 16 GB DDR3 RAM, GTX 970 3584 MB VRAM
 
n0b0dyDate: Thursday, 07.04.2016, 16:59 | Message # 2115
Explorer
Group: Users
Pirate
Messages: 297
Status: Offline
Quote SpaceEngineer ()
No, you can't. SE will use your galaxy/model script as a new model. But if it have the same name as some of the default models, unexpected bugs may occur. And of course the script for a model must be complete, ie have all fields.


But I did. And it worked wacko . I just left only the modified Milky Way script (all of it of course) and deleted all other scripts. When I restarted SE everything loaded properly. Milky Way was modified and all other galaxies looked the same. Anyway, so if I want to do it ''properly'': I copy/paste original model.cfg from data\models\galaxies into addons\models\galaxies and change parameters of the galaxy that I want to change, leave all other galaxy scripts unchanged and save under a different filename? e.g. ''mygalmodel.cfg''. Or do I leave the filename unchanged?

Quote SpaceEngineer ()
Because they are indeed relatively bright, if your planet is not located in the outer spiral arms, like Earth.


But the galactic core and even the galactic disk seems too bright with default script even from earth / sol system. Anyway
if the seed changes I probably want change any parameters..
 
Forum » SpaceEngine » Archive » Work progress and public beta test - 0.9.7.4
Search: