Tye-dyed bowling ball is only if all the cloud layers are on the same level. Various layers at different heights with shadows and parallax between them would look quite a bit better than that.
Lovely video. I especially like the smaller divotted âbubblyâ surface effect. While the larger boulder surface looks fine up close, from a distance I must say they look mighty odd. Partly down to the distant texture being a bit of a flat colour, but overuse and strange placement are also factors. Surrounded by other rocky features or up against a cliff they look nice, spread across a large area and surrounded by flat grass not so much.
Must agree that the sooner the front page gets some love the better. I was a full month late coming to these forums because I simply had no idea they existed yet. I donât really pay attention to twitter and had presumed that if there were any updates on the website side of things they would be visible (in one way or another) from the main page. It was complete luck that I one day clicked the community tab for the hell of it, fully expecting to find the âcoming soonâ message I had been greeted with in the past.
As said by others. Great video.
This planet indeed looks Alien and Earth like at the same time.
Even though thereâs still room for improvement I would definitely say the terrain is more then Kickstarter proof ⌠the Gas Planet too.
As with clouds from the outside the atmosphere. Yet, thatâs not what they have, so I donât understand why you brought it up. I thought you were trying to clarify the difference, not substantiate it.
The sun is also âfakedâ by a solid body.
No, a more subtle colour pallets is all thatâs required for that. Give that planet a deep blue background with white clouds and it wouldnât look so far off from a Neptunian-like world.
Not what Iâm talking about, but thanks for contributing something meaningful.
[quote=âKichae, post:26, topic:137â]
Indicable said:
They donât look good from above. Volumetric rendering will help the gas giant look like itâs not a tie-dyed bowling ball.
No, a more subtle colour pallets is all thatâs required for that. Give that planet a deep blue background with white clouds and it wouldnât look so far off from a Neptunian-like world.[/quote]
Yeah, Neptune seems more opaque than Jupiter or Saturn. Part of the problem seems to be the noise procedure. It appears Flavien is only stretching noise laterally about the poles. Well, I think he can get better results if he uses a greater exponent for pole-lateral interpolation on larger recursions of the fractal; progressively decreasing for smaller, more granular recursions. Interpolation irregularity is an element a lot of fractal noise routines are missing. Itâd be interesting to see what happens when one fractal noise function bends interpolation by directly sampling exponents derived from two-channels of more fractal noise.
Finally, itâs been such a long time. 
3 Likes
Hey Freeman.
Have you guys considered lower level LOD detail steps? Iâm not a programmer so point out the bullshit but things like rendering far-away targets as sprites or the âgeneric cruiserâ low-poly model? For the sprites i would think to render each ship from 14 equilateral sides and go with this basic logic,i will assume a 1000km visibility range for argumentâs sake:
- At 1000km: Spawn as low-quality sprite. No animation or texture, just a flat sillouette.
- 800km: Textured sprite with blinking lights for shots, engines, etcâŚ
- 600km: Basic very-low-poly model (sub-100 polygons) with no textures, just a flat average surface colour.
- 500km: Better polycount (>2000) and basic textures
- 400km: Half-poly model
- 300km+ regular LOD from here on.
Things like that. This would allow for rendering of many more ships on the screen without taxing the system. As for the connection issues of syncing that many ships on each client i would assume the same logical steps:
- 1000km: every ship updates its location every ~10 seconds (it can be 20 or 30). The local ship object will move towards that location within the same time as the updates go. Meaning it takes 10 seconds for said ship to reach the updated location and it will seem as if that ship is moving just fine even tho it is updated at 0.1Hz. In the event of an update coming too late have that object keep moving and if it needs to turn have it turn as if nothing happened. This way the server can throttle many objects that are not in direct contact with the player ship/client and maintain a believable simulation of âfakeâ spaceships.
- As distance decreases so does the the time between updates so as ships get closer to the player they update their location more often to appear seamless. Ships at, say, 300km could update once a second so it takes 1 second for said ships to move between each updated waypoin, tho this can lead to funky behaviour in a dogfight XD.
- When ships get close enough for combat then switch to the proper combat system.
- This means the ships locations using this system is not the ârealâ location but simply an approximation. The server can throttle and delay these updates (say from 10 to 14 seconds) if connection is slowed during a battle. This still allows for the player to see where the far-away ships are and move to them if needed and they would update more often as the player gets closer.
Seing a normal ship from 100km away seems to be rather dificult.
But I agree that the ideas posted sound interesting. Just cut the distances in half.
At 300 kilometers, most ships wouldnât even show up on screen. One of the other forums I frequent (a space art forum) has a tool which will calculate the size of a given object at any distance, using nothing more than size, distance, image width, and image field of view. I assumed an fov of 60 on my 1440x900 screen, and calculated the sizes of a 100 meter ship, 1 kilometer ship, and 5 kilometer (the largest possible ship size allowed, based on the old CDD [and I have no reason to believe that it would be any different now]) ship:
Thatâs 23, 5, and 1/2 pixel, from top to bottom, for the 5km, 1km, and 100m ships, respectively. The 5 kilometer ship is the only one of the three you could justify even having an on-screen LOD for, let alone one with any detail, with the other two being better represented by icons. To get the same on screen size for the other two, you would have to move to within 60 kilometers of the 1km ship, and 6 kilometers for the 100 meter ship. At 300 kilometers, colossi are shaded blobs and anything less is a dot, at best, and more likely wouldnât even render at all.
Lomsorâs right on the money, but way off on how much your distances need to shrink. Which is by at least three quarters (1000 becomes 250, etc.).
Better would be to calculate the LOD by a tool lile the one TerranAmbassador mentioned.
LOD detemined by actual size on screen.
[quote=âTerranAmbass, post:32, topic:137â]At 300 kilometers, most ships wouldnât even show up on screen.[/quote]Read: i will assume a 1000km visibility range for argumentâs sake.
It was arbitrary, simply to exemplify.
I have two questions for you:
-
How was I supposed to read something you didnât write? Really, I would LOVE to know.
-
That changesâŚwhat, exactly? Even if, as you say, the numbers you came up with were arbitrary, they were still wrong, and were a poor example. But ignoring that, I did nothing that you did not ask for. I saw bullshit, and I called it, to be absolutely blunt. There is nothing wrong with the system itself, beyond having a probably larger number of steps than necessary, but your âfor argumentâs sakeâ ranges were WAY off. So, âfor arguments sakeâ, I examined them using tools at my disposal, and then corrected them. If I came off as overly harsh or critical, I apologize, as that was not my intention, but my post, and the contents thereof, stands.
EDIT:
Felt the urge to respond to this.
I donât think that would be practical. Iâm no coder, but the calculations that the tool I mentioned uses are likely to be rather complex. Probably too much so to be done on the fly like that, forget about the LOD itself. Itâd be simpler, and probably more efficient, to just hand-model a couple of LOD stages (in addition to the full-detail model) for when the model is actually close enough to justify rendering, and just use icons everywhere else.
1 Like
If I remember right, one of the features of the Inovae engine is automatically generated LOD models. Even the old Ase2Bin had it.
Well. Iâm suggesting to have different LOD stages for different sizes of objects.
So for instance:
100m Ship
0 to 100m distance = best model
100 to 500m distance = stage 2 model
500 to 1k distance = stage 3 model
5km Ship
0 to 1k distance = best model
1k to 3k distance = stage 2 model
3k to 10k distance = stage 3 model
Something aproximate to that. No idea how Inovae handels LOD but it is probably allready programmed.
Yeah the engine had some form of an automatic LOD before, and while I canât be sure if that is still the case, Im betting they are certainly aware that they can use LOD and a bunch of other tricks for optimization. Discussing this here makes no sense for a bunch of reasons and its just derailing the topic.
If you still want to discuss anything, just click on the â+â on the right side of a post to reply as a new topic, and keep things in their right place, There is a âsuggestionsâ category made just for that.
Erhm⌠I know this isnât what the thread is about but after what you said about seeing BSâŚ
What calculations do you think have to be run for every object in every frame of any graphical rendering to figure out how large said objects should be in that frame? The effective cost is something like 10 CPU cycles, some of which can go on dedicated pipelines in most CPUs. I wouldnât be surprised if GPUs had dedicated pipelines for just this calculation.
Hi, Could you upload the original video to skydrive & googledrive, it can save your server bandwidth.