Русский New site

Advanced search

[ New messages · Forum rules · Members ]
Page 8 of 41«126789104041»
Forum » SpaceEngine » Archive » Work progress 0.9.7.1
Work progress 0.9.7.1
SpaceEngineerDate: Sunday, 16.06.2013, 09:54 | Message # 106
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4795
Status: Offline
Quote (SHW)
Yes. Semi transparent material requires additional work with polygon sorting.

You mean 'No'. Alpha testing is just discard the pixel if its alpha < 0.5. Semi-transparent textures is a alpha blending, and requires two-pass render with sorting of polygons. This is relatively hard to implement at this stage.





 
HarbingerDawnDate: Sunday, 16.06.2013, 11:14 | Message # 107
Cosmic Curator
Group: Administrators
United States
Messages: 8711
Status: Offline
Quote (SpaceEngineer)
You mean 'No'.

Actually, he does mean yes. The question he quoted and answered was asking if transparency was either totally on or totally off with this system, and the answer is yes it is. The answer no would apply to whether semi-transparency is supported, but that's not the part of Doc's post that he quoted.





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
 
SalvoDate: Sunday, 16.06.2013, 12:26 | Message # 108
Star Engineer
Group: Local Moderators
Italy
Messages: 1400
Status: Offline
Misunderstandings... wacko




The universe is not required to be in perfect harmony with human ambition.

CPU: Intel Core i7 4770 GPU: ASUS Radeon R9 270 RAM: 8 GBs

(still don't know why everyone is doing this...)
 
smjjamesDate: Wednesday, 19.06.2013, 01:13 | Message # 109
World Builder
Group: Users
United States
Messages: 913
Status: Offline
SpaceEngineer, I'm just wondering if you got the seed bug with open cliusters solved? I'm just asking because I'd like to be able to explore the open cluster stars without them dissapearing on me if I am at a cool location and I crash or something.




 
Gondor2222Date: Sunday, 30.06.2013, 07:34 | Message # 110
Space Pilot
Group: Users
United States
Messages: 92
Status: Offline
It would probably be incredibly simple to implement circular orbits around a body at a certain height- we already have a mechanism that allows us to revolve a certain distance around a body (by default it appears to be holding the right mouse button and dragging). All that would need to be done is have this movement automated at a certain speed regardless of the camera's orientation.
Also, are there plans to allow a body's apparent magnitude to change when it's eclipsed/transited? Or is this sort of measurement not typically included in measurements of apparent magnitude?
 
HarbingerDawnDate: Sunday, 30.06.2013, 16:08 | Message # 111
Cosmic Curator
Group: Administrators
United States
Messages: 8711
Status: Offline
Quote (Gondor2222)
Also, are there plans to allow a body's apparent magnitude to change when it's eclipsed/transited?

This already happens.





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
 
Gondor2222Date: Monday, 01.07.2013, 08:24 | Message # 112
Space Pilot
Group: Users
United States
Messages: 92
Status: Offline
When I move a planet/moon between myself and the sun so that it blocks all of the sun's light, and then select the sun's apparent magnitude shown in the data is the same as if it were not blocked.
 
midtskogenDate: Monday, 01.07.2013, 09:07 | Message # 113
Star Engineer
Group: Users
Norway
Messages: 1667
Status: Offline
The apparent magnitude assumes by definition that there is nothing obstructing the view, not even an atmosphere. Otherwise it would be a pretty meaningless unit. You wouldn't claim that the sun's apparent magnitude drops by 2 if you put sunglasses on, or by 10 every time you blink.

However, if you move into the shadow of a planet or moon, your apparent magnitude drops for an observer, and I believe this is what SE has implemented.

EDIT: I realise that whether it would be meaningful depends on how local the obstruction is. So we don't say that the apparent magnitude of the sun drops when the sun sets (Earth eclipses the sun), usually not when the Moon eclipses the sun, but perhaps we do when Venus or Mercury transits the sun or when exoplanets transit, and we do for things like eclipsing binaries, but in case of the latter it's the combined magnitude of two objects that change, not a single body.





NIL DIFFICILE VOLENTI


Edited by midtskogen - Monday, 01.07.2013, 10:07
 
HarbingerDawnDate: Monday, 01.07.2013, 17:03 | Message # 114
Cosmic Curator
Group: Administrators
United States
Messages: 8711
Status: Offline
Quote (Gondor2222)
and then select the sun's apparent magnitude shown in the data is the same as if it were not blocked.

Like midtskogen said, that's not how it works. Apparent magnitude is the brightness that an object is from a certain distance and angle from any given time. Just because the sun is behind the planet does not mean that the sun itself has gotten darker, you just can't see it. However, when the moon goes behind the planet and into its shadow, the moon itself DOES get darker, so its magnitude does change.





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
 
Gondor2222Date: Tuesday, 02.07.2013, 07:44 | Message # 115
Space Pilot
Group: Users
United States
Messages: 92
Status: Offline
So it calculates the change in apparent magnitude of an object with a shadow cast on it, but not a change in the apparent brightness of the object producing the light.
In that case can we have a line in the body's information when it's selected that tells us what percent of its incoming radiation is blocked from the viewer by another body? I understand this could be done with a calculator using the ratio of the squares of the apparent sizes of the light body and the occulting body, but a line telling us this would be nice.
 
SpaceEngineerDate: Thursday, 04.07.2013, 22:51 | Message # 116
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4795
Status: Offline
Implemented modular space ships. Remember that huge ship from default ships pack? Its model consumes 24 Mb of VRAM. Imagine a small fleet of (different) ships of such complexity...



It is obviously that this ship is built (with SHW 's editor) of few dozen modules. So what if we save in VRAM only these modules, and draw them many times according to "ship scheme". This is a modular ship approach. The result is pretty cool regarding to economy of memory. This (a bit updated) modular ship uses 3700 individual modules, but consumes only 1.7 Mb of VRAM, because there are only 20 different models of modules. And more, a huge fleet of ships build by SHW editor will consume only 1.7 Mb of VRAM!



The bad news s performance. The old monolith model running at 130 FPS, while new one only at 30 FPS. Maybe if I implement supporting of hardware instancing, it will fix the issue (but only for modern graphics cards). Or we may use hybrid method: export frames and shields as a single mesh, because they are 90% of the model, but render other modules individually. Or just made frame segments and shield tiles bigger. And, of course, 3700 modules is a pretty complex ship, in real game it may be useless. For example, updated SHW-Y model uses only 1200 modules, and running at 60 FPS.



Now I working on simplified ship mod installing system, and first simple ships manager. Just copy mod files into SE folder, and ship becomes available in the build menu. Then you may click "Build" button to add a ship to your fleet. Or you may select a ship from your fleet and click a funny "Destroy" button to get rid of this ship. Buttons to rename and (in future) re-color your ship will also be there. And you may organize your ships in any number of fleets, like in strategy games. It will simplify using the ships manager, if you have many ships pack mods installed. And commands like "Warp here" or "Warp there" will be available for entire fleets, as long as something like "Arrange into a grid" just for fun and debug purpose.





 
HarbingerDawnDate: Thursday, 04.07.2013, 23:20 | Message # 117
Cosmic Curator
Group: Administrators
United States
Messages: 8711
Status: Offline
I'm very excited about all the work you're doing and I am eagerly awaiting the next version. I hate to ruin the mood by asking this next question, but:

Might it have been a better idea to do the bugfixes and terrain update as 0.9.7.1 and released that quickly, and worked on ship updates as 0.9.7.2 since those do not need to be done as quickly as the other things?





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
 
LiveLife42Date: Friday, 05.07.2013, 07:31 | Message # 118
Explorer
Group: Users
United States
Messages: 272
Status: Offline
Quote (HarbingerDawn)
Might it have been a better idea to do the bugfixes and terrain update as 0.9.7.1 and released that quickly, and worked on ship updates as 0.9.7.2 since those do not need to be done as quickly as the other things?

I agree on harbinger with that, might have been better that way happy





PC: Intel Core i7-3770K o/c 4.6 Ghz Quad Core, 16GB DDR3 o/c 1866 Mhz, EVGA GeForce 980Ti with 6GB VRAM

Edited by LiveLife42 - Friday, 05.07.2013, 07:31
 
LevArrisDate: Friday, 05.07.2013, 08:18 | Message # 119
Observer
Group: Users
Germany
Messages: 12
Status: Offline
Quote (HarbingerDawn)
I'm very excited about all the work you're doing and I am eagerly awaiting the next version. I hate to ruin the mood by asking this next question, but:

Might it have been a better idea to do the bugfixes and terrain update as 0.9.7.1 and released that quickly, and worked on ship updates as 0.9.7.2 since those do not need to be done as quickly as the other things?


I do support HarbingerDawn's point of view. I think splitting issues into a) major bugs, b) minor bugs, c) improvements/features makes sense. Also aligning the release process to a more transparent workflow based on the categories above would help a lot to maintain and increase the happiness of the fanbase. Simply because it makes a more professional impression.

I also expected 0.9.7.1 to come out quickly as a bugfix release. I love SpaceEngine, but (at least for me) 0.9.7.0 is currently unplayable, as major issues like the absence of life Terras in single star systems, memory leaks and slowdowns in the system browser and some weird crashes during travelling at high speeds are not fun at all. As far as I can read in the forum, those issue have been already fixed since weeks. So why not releasing a patch before working on minor improvements and new features?

Please don't get me wrong, I do respect the amazing dedication and work of SpaceEngineer on this project. But I have some difficulties to understand the schema behind the current release process of SE (as a software developer myself)...
Maybe the MoSCoW method (see Wiki) would help to categorize future patch releases :).

Best regards,

Lev
 
SpaceEngineerDate: Friday, 05.07.2013, 11:36 | Message # 120
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4795
Status: Offline
Quote (HarbingerDawn)
Might it have been a better idea to do the bugfixes and terrain update as 0.9.7.1 and released that quickly, and worked on ship updates as 0.9.7.2 since those do not need to be done as quickly as the other things?

It is impossible. SE source code already have many changes related to ships. I can't "undo" them without ruining other stuff.
Remember I am the only programmer work on SE. I can't spend every day finding bugs that MUST be fixed. Not all of them is easy to find! Other is impossible to fix without some huge reorganizing work. Fixing something may require a months of unsuccessful search, while implementing a new cool feature requires a few days! I'm just get bored of weeks of bugfixes and start working on new features. You have to accept with my way of working.





 
Forum » SpaceEngine » Archive » Work progress 0.9.7.1
Page 8 of 41«126789104041»
Search: