Project Perfect Mod Forums
:: Home :: Get Hosted :: PPM FAQ :: Forum FAQ :: Privacy Policy :: Search :: Memberlist :: Usergroups :: Register :: Profile :: Log in to check your private messages :: Log in ::


The time now is Thu Mar 28, 2024 12:07 pm
All times are UTC + 0
OpenRA Blog
Moderators: Global Moderators, OpenRA Moderators
Post new topic   Reply to topic Page 4 of 4 [178 Posts] Mark the topic unread ::  View previous topic :: View next topic
Goto page: Previous 1, 2, 3, 4
Author Message
pchote
Rocket Infantry


Joined: 06 Feb 2015

PostPosted: Sat Jul 02, 2016 8:40 am    Post subject: Reply with quote  Mark this post and the followings unread

This is a simple and isolated interpolation problem.  The code for moving units through cells lerps the position and facing between their initial and final values on entering/leaving the cell.  This is wrong, and gives the behaviour we see where the unit slides in a different direction to its facing.

The fix is to make UpdateCenterLocation use a higher order interpolation that curves through the cell and sets the facing to the tangent of the path.  I imagine that the original games used a look up table, but we could do it more easily using splines.

Back to top
View user's profile Send private message
OmegaBolt
President


Joined: 21 Mar 2005
Location: York, England

PostPosted: Sat Jul 02, 2016 8:46 am    Post subject: Reply with quote  Mark this post and the followings unread

Iran wrote:
The vehicle turning logic and movement is a bit off, the turning especially looks weird. The turning is really, really smooth.
I agree however this is customisable in the mod. You can set the number of visual facings are taken from the voxel.

Back to top
View user's profile Send private message Send e-mail
Iran
Pyro Sniper


Joined: 23 Mar 2011

PostPosted: Sat Jul 02, 2016 11:38 am    Post subject: Reply with quote  Mark this post and the followings unread

Ah, does it look better than?

Other than that both Tiberian Sun and RA2 look a lot better under OpenRA. Maybe it's time to add OpenRA support to CnCNet.

Back to top
View user's profile Send private message
G-E
Defense Minister


Joined: 09 Feb 2015

PostPosted: Sat Jul 02, 2016 10:55 pm    Post subject: Reply with quote  Mark this post and the followings unread

I don't see why some facing increment isn't updated in parallel to the rendering, afterall if it can display the facing, it should be aware of the facing no?

Many of the movement issues between cells would be fixed if the ROT was linked to speed, and the direction of travel was linked to ROT (facing) wouldn't they? I don't see any spline calculations being necessary, that presupposes knowing the entire trajectory regardless of acceleration or other factors, which seems like the wrong approach.

I'd argue the WW engine actually does a little preplanning for aircraft, and doesn't take into account facing at a granular level which causes aircraft in some cases (when the engine is busy or the aircraft is too fast) to turn backwards instead of a banking forward turn. If the movement was always relative to the previous movement, any lag would just make the turning more jerky as precision is lost, nothing major.

_________________
http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai

Back to top
View user's profile Send private message
Matthias M.
Stealth Laser Trooper


Joined: 15 Jun 2012
Location: Germany

PostPosted: Sun Jul 03, 2016 7:48 am    Post subject: Reply with quote  Mark this post and the followings unread

Iran wrote:
Maybe it's time to add OpenRA support to CnCNet.


That might be easy from a technical standpoint. Our "global chat" also uses IRC and joining servers works with openra:// links. Loading the server list is a matter of parsing a .yaml or .json file. http://www.openra.net/games/

Back to top
View user's profile Send private message
pchote
Rocket Infantry


Joined: 06 Feb 2015

PostPosted: Sun Aug 07, 2016 6:51 pm    Post subject: Reply with quote  Mark this post and the followings unread

#11788 should fix the worst of the smooth movement complaints in the next release.

Back to top
View user's profile Send private message
pchote
Rocket Infantry


Joined: 06 Feb 2015

PostPosted: Tue Aug 23, 2016 7:27 pm    Post subject: Reply with quote  Mark this post and the followings unread

The per-pixel depth calculations that I showed off back on page 3 of this thread (nearly a year ago now) are finally finished, and i'm going to strongly enourage our other devs to get the final PRs reviewed and merged before our next release.

While it may not seem like a big deal if you don't understand how our rendering works, this was actually our single biggest blocker for releasing the gen2 (isometric/heightmapped) mods.  There's still a lot more work to go around the edges, but our fundamental engine design now finally supports proper isometric rendering.  Like you might expect, we've gone further than TS's limited global buildngz.shp and support per-sequence depth data: this means that you can have pixel-perfect intersections, just like real 3d models, if you configure your artwork pipeline to render out depth sprites along with your normal shps.

The most obvious results are that units/weapons/etc now disappear behind cliffs, and don't disappear behind flat things like gates or building bibs.


Back to top
View user's profile Send private message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Tue Aug 23, 2016 8:07 pm    Post subject: Reply with quote  Mark this post and the followings unread

Rating 10 out of 10! Perfect! of  Rating 10 out of 10! Perfect!
Applauses!  Approved!


I never checked out buildngz.shp. Can you describe shortly where this is used and how it works? So far, i only used the ZAdjust keys to hide objects behind the building or ActiveAnim.

Do you plan to incorporate such height infos into projectile hit calculations? Allowing high flying projectiles to fly over low building parts and hit high building parts.

_________________
SHP Artist of Twisted Insurrection:  Nod buildings

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant, 1 Scrin unit, 1 GDI building

Tools
Image Shaper______TMP Shop______C&C Executable Modifier

Back to top
View user's profile Send private message
Banshee
Supreme Banshee


Also Known As: banshee_revora (Steam)
Joined: 15 Aug 2002
Location: Brazil

PostPosted: Tue Aug 23, 2016 9:52 pm    Post subject: Reply with quote  Mark this post and the followings unread

Congratulations guys. I'm a bit silent in this topic, but I'm watching it and I'm very interested in the results posted here Smile.

Back to top
View user's profile Send private message Visit poster's website Skype Account
pchote
Rocket Infantry


Joined: 06 Feb 2015

PostPosted: Tue Aug 23, 2016 9:59 pm    Post subject: Reply with quote  Mark this post and the followings unread

Basically it defines a per-pixel z-offset that is applied to buildings so that the "x is in front of y" lines run diagonally, parallel to the cell edges, instead of horizontally across the sprite.

Why is this needed? Consider a building is that is much longer than it is wide, like the gate (lets call it G) in the screenshot above.  An actor A that is to the NW of the bottom cell should obviously be rendered behind the gate (A < G), and an actor B that is to the SE of the top cell should obviously be drawn in front of the gate (G < B).  But this is logically impossible if you use the simple rule for "things closer to the bottom of the screen are drawn in front" (which is the best you can do if you have flat sprites with no extra info), because B < A but A < G < B implies B > A.  If you render the world as a bunch of flat planes then you are forced to draw one actor behind another that it should visually appear in front of.  This produces bugs like ra2#147 - notice that the tesla trooper is indeed "behind" the center of the telsa reactor's footprint.

The original TS has hardcoded rules for aligning the pixel offsets stored in buildngz.shp to the footprint (this will be one of the reasons why TS/RA2 didn't let you define arbitrary footprints) and other hardcoded rules for things like bib sprites that don't use it.  I've set it up in OpenRA so that everything can be defined per-sequence, so you can use depth maps that correspond to the actual sprite instead of just a generic rectangular box.

There's no plans to let these affect projectile hit calculations (we have a hard rule that gameplay simulation state can't depend on artwork or render state), but our collision logic is already much more flexible than the original games.  It wouldn't be a huge effort to define a rough 3d collision shape (made out of boxes or spheres) in mod code that does the same thing.

Back to top
View user's profile Send private message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Tue Aug 23, 2016 10:24 pm    Post subject: Reply with quote  Mark this post and the followings unread

thanks for the explanation.
Crazy what kind of techniques were implemented by WW to get the isometric view work.
pchote wrote:
because B < A but A < G < B implies B > A.

i like such pure and simple logic. Smile

_________________
SHP Artist of Twisted Insurrection:  Nod buildings

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant, 1 Scrin unit, 1 GDI building

Tools
Image Shaper______TMP Shop______C&C Executable Modifier

Back to top
View user's profile Send private message
pchote
Rocket Infantry


Joined: 06 Feb 2015

PostPosted: Sat Aug 27, 2016 9:15 pm    Post subject: Reply with quote  Mark this post and the followings unread

Working on these features sometimes gives some fun insights into the original game's development process.

A side-effect of the depth-correct rendering is that the near-ground-level laser turret beams clip through walls in a rather ugly way



So, how did WW avoid this?  They cheat, of course!



Notice that the central core of the beam clips through the wall in almost exactly the same way.  They then hide this by rendering a second (wider, more translucent) beam over the top with a large enough positive Z-offset to cover up the clipping.
We can measure the z-offset between the 'real' and 'z-fudged' beams by shooting through a larger structure and counting the pixel offset between the two cutoff points



This works out as 12px, or half a cell, which makes sense.

At some point I'll add the option to render the second z-fudged beam to our OpenRA lasers so that we can emulate this behaviour.

Back to top
View user's profile Send private message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Sat Aug 27, 2016 10:59 pm    Post subject: Reply with quote  Mark this post and the followings unread

the main beam should also get a z-fudge fix.
No reason to repeat WW mistakes or bad solutions.

It might be also nice if such a laser beam can be blocked by walls (though only if a certain key is set, like AffectedByWalls: true).


Would the current system respect the lasers start and end point height and render it correct above walls if for example the start point on the turret is 48 pixel higher?
In other words, does the laser effect have only 1 z-value for the entire line or different z-values along the line?


Is the main laser lines thickness adjustable via the weapons yaml? Could be a bit thinner to look more like TS

_________________
SHP Artist of Twisted Insurrection:  Nod buildings

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant, 1 Scrin unit, 1 GDI building

Tools
Image Shaper______TMP Shop______C&C Executable Modifier

Back to top
View user's profile Send private message
pchote
Rocket Infantry


Joined: 06 Feb 2015

PostPosted: Sun Aug 28, 2016 12:46 pm    Post subject: Reply with quote  Mark this post and the followings unread

The z-fudge isn't a fix, doing it to the main beam would just move the rendering glitches to other cases (e.g. low-flying aircraft going over the turret but under the beam).  The z-values vary along the line.

Blocking height and classes are already completely customizable... some discussion of that happened back on page 3.

Back to top
View user's profile Send private message
Matthias M.
Stealth Laser Trooper


Joined: 15 Jun 2012
Location: Germany

PostPosted: Mon Aug 29, 2016 5:55 am    Post subject: Reply with quote  Mark this post and the followings unread


Back to top
View user's profile Send private message
pchote
Rocket Infantry


Joined: 06 Feb 2015

PostPosted: Fri Nov 18, 2016 8:55 am    Post subject: Reply with quote  Mark this post and the followings unread

Work on TS is still ticking along slowly:
  • #12370 implements cliff visibility blocking.
  • #12371 implements low-bridge damage, demolition, and repairing.
  • reaperrr has done a great job finding and fixing z-sorting bugs in the sequence definitions plus other polish fixes (too many prs to list).



Back to top
View user's profile Send private message
Crimsonum
Seth


Joined: 14 Jul 2005
Location: Fineland

PostPosted: Fri Nov 18, 2016 9:24 am    Post subject: Reply with quote  Mark this post and the followings unread

Very nice, looks almost identical to how TS did it, but smoother.

_________________


Back to top
View user's profile Send private message
SMIFFGIG
General


Joined: 03 Mar 2003
Location: Great Britain

PostPosted: Fri Nov 18, 2016 11:54 am    Post subject: Reply with quote  Mark this post and the followings unread

Amazing, I love what you guys are doing!

Just curious, will units on higher cells have increased visibility over the lower cells (e.g. Unit on cliff).

If I remember correctly this logic was (at least to some extent) existent in TS but unused.

_________________

Back to top
View user's profile Send private message Send e-mail Skype Account
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Fri Nov 18, 2016 2:07 pm    Post subject: Reply with quote  Mark this post and the followings unread

any progress is good progress, no matter how slow it is. Smile

Higher object postion towards lower target providing bigger sight and weapon range would be indeed a very nice feature.

TS has this implemented in a broken way (LeptonsPerSightIncrease / LeptonsPerFireIncrease), why it was never enabled (keys using very high values in rules.ini).
Because here it was an absolute factor. Every map height level giving a unit a certain bonus to sight and weapon range, regardless of the targets height position.
So if a flat map was entirely on height 12, all units would have a higher sight/range than on a flat map that is on height 0.

_________________
SHP Artist of Twisted Insurrection:  Nod buildings

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant, 1 Scrin unit, 1 GDI building

Tools
Image Shaper______TMP Shop______C&C Executable Modifier

Last edited by Lin Kuei Ominae on Fri Nov 18, 2016 2:11 pm; edited 1 time in total

Back to top
View user's profile Send private message
Crimsonum
Seth


Joined: 14 Jul 2005
Location: Fineland

PostPosted: Fri Nov 18, 2016 2:10 pm    Post subject: Reply with quote  Mark this post and the followings unread

The logic exists in TS, but it's not very well implemented. IIRC, units on high ground have overall longer sight and weapon range than units on lower ground. Obviously a more realistic way would be to have the range increase only in relation to lower ground (i.e. when the unit is standing near the edge of a cliff/slope).

EDIT: LKO beat me to it. AFAIK the logic was enabled in TS, at least LeptonsPerSightIncrease and LeptonsPerFireIncrease had achievable values (2000 leptons for both, meaning approximately 8 height levels).

I also remember testing it and IIRC I found that artilery on map Height level 4 could fire a cell farther than artillery on Height 0, and on Height 8 they could fire two cells farther than Height 0, respectively. The range increase could've been explained by the ballistic nature of their projectile, though, as the target was located at Height 0 in all cases.

_________________


Back to top
View user's profile Send private message
Graion Dilach
Defense Minister


Joined: 22 Nov 2010
Location: Iszkaszentgyorgy, Hungary

PostPosted: Fri Nov 18, 2016 3:17 pm    Post subject: Reply with quote  Mark this post and the followings unread

What OpenRA got is basically a hard-check against a defined-on-the-sight-trait value, heightlevels above that value stay unrevealed. This defaults to -1 (>0 values mean disabled) and is set to 3 on the screenshot.

_________________
"If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more...

Back to top
View user's profile Send private message Visit poster's website ModDB Profile ID
pchote
Rocket Infantry


Joined: 06 Feb 2015

PostPosted: Fri Nov 18, 2016 5:08 pm    Post subject: Reply with quote  Mark this post and the followings unread

Like Graion said, this currently only supports a cutoff for cells above the actor.  It would be easy to add height bonuses if someone defined a set of parameters and filter criteria that maps a height delta to a sight range.  I won't be doing that myself though.

Back to top
View user's profile Send private message
pchote
Rocket Infantry


Joined: 06 Feb 2015

PostPosted: Sat Nov 26, 2016 10:06 pm    Post subject: Reply with quote  Mark this post and the followings unread

Some more progress towards TS-style terrain: #12371 and #12430 implement ground-level bridges, and #12431 fixes the issue where units travel too far behind cliffs.

#12396 fixes the graphical glitches with carryalls and deployer units, and is just a small part of the upgrades system overhaul that will make it much more powerful and modder friendly.

Back to top
View user's profile Send private message
pchote
Rocket Infantry


Joined: 06 Feb 2015

PostPosted: Sun Jan 15, 2017 2:22 pm    Post subject: Reply with quote  Mark this post and the followings unread

We have some more great TS progress in the review queue with #12571 implementing the bouncing disc logic, #12557 emulating the classic reveal-on-fire logic, and #12577 adding subterranean and jumpjet units plus tunnels and (indestructable but usable placeholders for) elevated bridges.

Back to top
View user's profile Send private message
kainzal
Guest




PostPosted: Tue Mar 21, 2017 9:38 pm    Post subject: Reply with quote  Mark this post and the followings unread

it would be great if you added the explosion-effects of buildings and vehicles of Tiberian Sun Dusk .. ..they look really great.. ..look: .. https://vimeo.com/1156606 ..greetings..

Back to top
pchote
Rocket Infantry


Joined: 06 Feb 2015

PostPosted: Sun May 07, 2017 10:03 pm    Post subject: Reply with quote  Mark this post and the followings unread

It's been a while since anybody has posted here, so here's an update on what we've been working on for TS:
  • I implemented Laser fences (#13025).
  • reaperrr implemented tiberium floaters (#13174).
  • MustaphaTR set up the tech level options (#12984).
  • MustaphaTR polished the order of our sidebar cameos (#13053).
  • reaperrr worked on a bunch of balance and gameplay fixes (#12921, #12606, #13164).
  • Me and (mainly) reaperrr worked on a bunch more graphical fixes (#12993, #13048, #13080, #13210).
  • Me and reaperrr fixed most of the remaining issues with Jumpjets, subterranean units, and tunnels (#12924, #13149, #13159, #13160, #13162, #13217).  These now feel well integrated with the game.
  • atlimit8 has been working on replacing the remaining uses of actor-level disabling with trait-level conditions (#12955, #12996), which will fix several issues with the EMP cannon and stealth generators.
  • reaperrr has been working on Juggernauts (#13041), which has been easier said than done.
  • I finally got around to fixing our unintuitive range parsing in the isometric mods (#13253).
The mod support changes mentioned in our last news post are now also complete, and the new mod template has reached feature parity with the old modding setup.  This has been a major task that will make life significantly better for modders, once they get over the initial learning curve.

Back to top
View user's profile Send private message
Matthias M.
Stealth Laser Trooper


Joined: 15 Jun 2012
Location: Germany

PostPosted: Tue Dec 21, 2021 9:58 pm    Post subject: Reply with quote  Mark this post and the followings unread

It's been a while since #18310 added Tiberian Sun style lighting



which is also useable in 2D mods to add some visual depth


Back to top
View user's profile Send private message
MasterHaosis
General


Joined: 01 Nov 2010
Location: Serbia

PostPosted: Wed Dec 29, 2021 5:01 am    Post subject: Reply with quote  Mark this post and the followings unread

Whoa nice lighting man! Good work

_________________

PPM Halloween Season 2021

Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic Page 4 of 4 [178 Posts] Goto page: Previous 1, 2, 3, 4
Mark the topic unread ::  View previous topic :: View next topic
 
Share on TwitterShare on FacebookShare on Google+Share on DiggShare on RedditShare on PInterestShare on Del.icio.usShare on Stumble Upon
Quick Reply
Username:


If you are visually impaired or cannot otherwise answer the challenges below please contact the Administrator for help.


Write only two of the following words separated by a sharp: Brotherhood, unity, peace! 

 
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © phpBB Group

[ Time: 0.2060s ][ Queries: 11 (0.0138s) ][ Debug on ]