Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Sat Nov 02, 2013 12:07 am Post subject:
Welcome to OpenRA Editing Forums!
Subject description: Who commands the past, controls the future.
Hello everyone!
Welcome to the OpenRA Editing Forums! This forum is the place you have to ask modding help, post your modding doubts and figure out new techniques to bypass the limits of the game and recruit members for your mod. Use the Private/Public Mod Announcements to tease and gather fans for your mod.
For those who are starting to mod the game, we recommend the following tools:
-> OpenRA: The game itself, which comes with a map editor.
-> NotePad++: This advanced text editor edits everything, including YAML files. It includes several features to make text editing much easier and it's totally free.
-> XCC Mixer: This tool is useful to browse the .mix files, manipulate them and do almost any kind of conversion that you'd do for all assets.
-> OS SHP Builder: This tool allows you to create and save .SHP files from both TD and TS file format. OpenRA is more used to deal with the TD format, although it seems to accept the TS one as well. OS SHP Builder produces reliable SHP (TS) files, while the SHP (TD) did not receive a proper amount of tests to confirm its stability.
Remember that we hold no responsibility for these tools. Use them at your own risk.
And finally, OpenRA also has a super-super secret placed known as http://content.open-ra.org/ where you can share and download resources for it. QUICK_EDIT
We recently added support for xcc local mix database.dat files so our in-game asset browser (Settings → Advanced → [x] Enable Asset Browser) will understand it. We also support the palette indexed PNG → SHP(TD) workflow and the Asset Browser wraps the command line utility with some GUI to make it a little more user friendly.
See https://github.com/OpenRA/OpenRA/wiki/Pixelart for some tutorials to convert file formats, use our tileset builder (only included in the full SDK, needs to be compiled yourself) and a 3DSMax → SHP(TD) tutorial.
This is not strictly true (sorry, I should have filed an issue about it at github long ago, but I keep forgetting), the problem is that community voxels use the XYZ scale values inside the voxel to scale it down ingame compared to its base dimensions, for a somewhat 'smoothing' effect, or to make it wider, shorter or whatever without having to redo the voxel. This works absolutely fine in TS and RA2, but OpenRA seems to treat those values as bounds instead, as a result any voxel with scale values lower than its actual dimensions will have parts cut off/shown at the wrong position.
Basically, at the moment modders would have to set the scale values to values identical with the voxels' dimensions and use OpenRA's yaml scale trait instead if they want to make the voxel appear smaller. QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sat Nov 02, 2013 12:50 pm Post subject:
I thought the beta SHP Builders already can save into SHP(TD) as intended...
Either way, my interest in this will be raised a lot:
- when I see this actor-traitsystem explained (a list is not an explanation)
- when this bug Reaperr mentioned gets fixed
- when isometric terrain support is added (not a necessity)
- and some proper tutorials wouldn't hurt
Because then I'd start a build of my mod on this thing. Gladly with the amount of TS/RA2 assets scattered within the community, we could build anything now. _________________ "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... QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sat Nov 02, 2013 1:45 pm Post subject:
Ohgod... you don't even have a hierarchy?!
I'm not sure if i want to work with this at all now... the actor individualism will gonna go bloated longtime.
I don't want to praise WW but their class hierarchy was a lot better approach IMO. _________________ "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... QUICK_EDIT
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Sat Nov 02, 2013 2:00 pm Post subject:
Quote:
I thought the beta SHP Builders already can save into SHP(TD) as intended...
Maybe it does. The version 3.36 did corrupt some SHP (TD) files. I've tried to fix that in 3.37 and didn't see it corrupting SHP (TD) anymore, but nobody tested the result. QUICK_EDIT
If you mean class hierarchy, then we have that, but more flexible due to our powerful rule inheritance https://github.com/OpenRA/OpenRA/blob/bleed/mods/ra/rules/defaults.yaml It saved me a lot of typing for the d2k mod where lot's of house actor definitions are inherited and extended. Last edited by Matthias M. on Sat Nov 02, 2013 3:02 pm; edited 1 time in total QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sat Nov 02, 2013 3:02 pm Post subject:
I think I'll try to cool up something when I have a break from my uni semester then to see how good this system is. (which'll happen around January)
Because I see we're totally in a different world. _________________ "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... QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sun Jul 20, 2014 10:41 am Post subject:
loldatharvester. IIRC OpenRA ignores either header or HVA Transform.
I'll keep an eye of this but I doubt it'll change my thoughts about the engine. _________________ "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... QUICK_EDIT
Hello world!
Much appreciated to Matthias for helping me to getting started.
Could you maybe write a short step by step guide how you got to your hello world? It might come in handy when others want to start an OpenRA project and i'm sure Matthias has better things to do than repeating his "getting started" tips again and again for everyone who wants to give OpenRA modding a try. _________________ SHP Artist of Twisted Insurrection: Nod buildings
The main trick I tried to explain is how you can use MiniYAML rule merging to get started fast. https://github.com/Mailaender/OpenRA/blob/rewire/mods/rewire/mod.yaml#L70 re-uses a lot of the existing TS mod files and simply adds new small rewire *.yaml files that only overwrite certain values that need to be adjusted by adding them on top of the list. The benefit is that things work out of the box and it is easier to maintain instead of just copy and pasting, because all the improvements made to the TS mod like my recent https://github.com/OpenRA/OpenRA/pull/5998 will automatically apply upon git fetch openra/bleed and rebase. QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sat May 16, 2015 7:02 pm Post subject:
Graion Dilach wrote:
OpenRA ignores either header or HVA Transform.
I'll keep an eye of this but I doubt it'll change my thoughts about the engine.
Time to correct myself.
1) WW ignores Scale in the voxel header and VXLSE default is 10x bigger than the value WW used. It's not OpenRA's blame.
2) It did not changed my thoughts alone, but now that I'm looking at it as a modder, I am definitely amazed and definitely orienting towards pro-OpenRA. It's certainly interesting as a C&C engine. That, and the Traits page became a lot more useful than it was a year ago. Kudos. _________________ "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... QUICK_EDIT
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Sat May 16, 2015 9:03 pm Post subject:
FYI, VXLSE III uses a bigger scale to make editing be viable. I don't think it is possible to have a minimum desirable when you edit the model with scale 1x. QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sat May 16, 2015 9:08 pm Post subject:
I talk about the Scale on the right and not magnification. _________________ "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... QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sun May 17, 2015 12:11 pm Post subject:
I never used your voxelizer, so I think it comes from the editor. _________________ "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... QUICK_EDIT
Okay, thanks for that information. However, there is something that everyone needs to be aware of about the voxelizer. In the voxelizer, by default, the bounds are set to 0.7 times what might be expected in order to scrunch the voxel pixels together, to prevent gaps appearing in Westwood Studios games, because they use pixels instead of cubes to represent the voxel data points. Since OpenRA apparently uses cubes, then that technique is totally unnecessary and may be detrimental. In the voxelizer, the setting is called "Voxel Dot Distance" and can be set to just 1 for OpenRA voxels. QUICK_EDIT
Right now OpenRA renders voxels as cubes (actually not, but what we do do produces an equivalent image on screen), but this is relatively slow.
At some point I plan on rewriting our voxel renderer to introduce the 1 voxel = 1 px assumption in an appropriately (un)scaled coordinate space.
That means that setting a large scale will give you a large square pixel on the screen instead of resolving the details of the cube, and you will get gaps if the voxel dot distance isn't set correctly. Having a correct dot distance and a large scale won't give you holes, however. QUICK_EDIT
You are actually going to downgrade the voxel renderer of OpenRA to be similar to the one in the Westwood Studios games?! It's not so good to scrunch the data points together to close gaps because then it causes another problem which is: details being occluded by pixels completely overlapping other pixels.
In case you are not aware, a lot of VXL files from the voxel editor do not have this problem and therefore appear quite pristine in game from certain simple angles because many artists instead use another technique to prevent gaps which is to make surfaces extra thick voxel-wise. However, this technique is extremely tedious for the artists because the voxelizer and the voxel editor will not do it automatically. Actually, I'm not sure if the voxel editor will do it. QUICK_EDIT
ViPr while I understand your concern from a technical standpoint, I don't think matching the game you are copying is a bad thing either...
As pointed out the people making voxels have learned all the tricks to make the voxels look good already, doesn't matter that it's not the ideal way, it is the known way. Seems silly asking everyone to relearn, or worse edit and re-render voxels for 2 wildly different rendering engines.
The RA2 engine creates some really interesting twisting effects when dots start overlapping. It appears the engine rotates the cubes/dots to always be level to the viewer, regardless of voxel angle.
It all comes down to performance. The current voxel renderer performance scales as roughly [2*(<voxel width> + <length> + <height>) + large constant] times slower than rendering a sprite: in practice, 100 ~ 1000 times slower. Rendering a sprite is very fast, but ~500 x <fast> x <a bunch of voxels> adds up to a lot of GPU/CPU time that could be better spent doing other things. By changing the way we do the rendering we may be able to win a factor of 10 improvement, which means 10 x more units could be rendered on screen (note: not quite that simple in reality) before performance drops. QUICK_EDIT
There's no need for the VXL files to be changed even slightly to render well in the ideal voxel renderer. VXL files, designed to look good in the official Westwood Studios engine, will look good in the ideal voxel renderer, but not necessarily vice versa.
I'm very disappointed that you guys are downgrading the OpenRA voxel renderer; that was what I was looking forward to the most; seeing voxels look much better finally.
Also, are you forgetting that here:
http://www.ppmforums.com/viewtopic.php?&t=35155
We discussed that the official games probably do not actually render the voxels most of the time. The voxels are possibly prerendered to convert them to a bunch of sprites, and then just those sprites are used most of the time instead, in my opinion. QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Mon May 18, 2015 11:32 pm Post subject:
G-E wrote:
the people making voxels have learned all the tricks to make the voxels look good already, doesn't matter that it's not the ideal way, it is the known way. Seems silly asking everyone to relearn, or worse edit and re-render voxels for 2 wildly different rendering engines.
Oh, wait, you're serious?
The RA2 voxel renderer is tolerable at it's finest. Yes, some people made nice voxels on it, but even those voxels look a LOT more better in OpenRA.
Mostly because OpenRA does not use the vpl and isn't limited by it.
ATM - besides fixing/maintaining Scale - the OpenRA voxelling style only differs from RA2 in that, for OpenRA you should always remove redundant voxels. That's like... yea, 2 clicks. And you're doing it not because of looks but for gaining performance.
G-E wrote:
The RA2 engine creates some really interesting twisting effects when dots start overlapping.
That's not interesting, that's a headache with random bugs (helicopter hides his own rotor blade, barrel overlaps turret - this can't even be fixed 100% unless you merge the barrel into the turret's section).
I can see why performance is an issue with the current renderer but I think it should be kept along anyway, as a Renderer: LegacyRenderer trait, and modders could set rare units to evade the visual degradation without that significant perf loss. _________________ "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... QUICK_EDIT
The RA2 voxel renderer is tolerable at it's finest. Yes, some people made nice voxels on it, but even those voxels look a LOT more better in OpenRA.
Mostly because OpenRA does not use the vpl and isn't limited by it.
I wasn't referring specifically to the vpl, that's not really the rendering equation merely the shading/colouring aspect; whether it uses a table for colour values or calculates them on the fly, it shouldn't affect the base rendering style.
Graion Dilach wrote:
That's not interesting, that's a headache with random bugs (helicopter hides his own rotor blade, barrel overlaps turret - this can't even be fixed 100% unless you merge the barrel into the turret's section).
Again that's not specifically a rendering problem with the voxels individually, the problem is how it defines hierarchy/occlusion, there's no need for the top most section to be rendered below a lower section if the dot positions don't overlap. I honestly don't understand how WW even made this bug...
Graion Dilach wrote:
I can see why performance is an issue with the current renderer but I think it should be kept along anyway, as a Renderer: LegacyRenderer trait, and modders could set rare units to evade the visual degradation without that significant perf loss.
Well in that case, why not have several renderers? Pick the one that suits your computer's performance the best, besides lag the local rendering wouldn't impact game mechanics or multiplay... QUICK_EDIT
I was thinking it might be a good idea to have the two different renderers in OpenRA, and then switch between them automatically according to the frame rate. However, because of the 2 methods used to make the voxels appear decent in the Westwood Studios type of voxel renderer (scrunching or redundant thickness), the voxels will not work so ideally in the ideal voxel renderer.
Redundant thickness during rendering uses extra memory and processing.
Scrunching causes loss of detail and what I call glittering or visual noise caused by too much detail fighting to appear in too few screen render samples. It can be countered somewhat by super-sampling.
Anyway, I hope you will stay flexible about the voxel renderer, and not completely discard superior rendering techniques. QUICK_EDIT
If the renderer was able to take advantage of multi-core cpus and gpus to do the grunt work, this would solve a lot of the issues for people with quad core 4ghz people like me. Realistically if each rendered voxel was divided into it's own thread, the cpu would handle the shuffling for you, and a few complex voxels wouldn't gum up the works.
Of course there's another possible avenue to speed things up, and that's automatically removing redundant voxel data when the game data is loading, which would allow us to continue making RA2 style models, without the performance overhead. I'm sure Banshee could donate the code for that, and in the early versions you could even have the aggressiveness adjustable to find the sweet spot by consensus. _________________ http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai QUICK_EDIT
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Fri May 22, 2015 12:01 am Post subject:
G-E wrote:
Of course there's another possible avenue to speed things up, and that's automatically removing redundant voxel data when the game data is loading, which would allow us to continue making RA2 style models, without the performance overhead. I'm sure Banshee could donate the code for that, and in the early versions you could even have the aggressiveness adjustable to find the sweet spot by consensus.
This is something that works better if it is preprocessed. It's not a duty from OpenRA itself. The developer can do it in the voxel editor instead. If the developer is sending an non-optimized voxel, it is not up to OpenRA to optimize it everytime it runs or check if it is optimized or not. QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Fri May 22, 2015 10:42 am Post subject:
It does. Read pchote again: all voxels are rendered as cubes. This includes the ones you can't even see.
Nonetheless, in my tests I could gain performance with removing redundant voxels from the ones I use.
The game takes advantage of multi-core cpus as well. _________________ "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... QUICK_EDIT
Actually it doesn't (note my: "actually not, but what we do do produces an equivalent image on screen" above). The current voxel renderer generates a set of textured slice planes, and so the overall performance and memory use scales with the overall width + height + length bounds but is essentially independent (note: not quite that simple) of the number of filled/empty voxels within each plane. QUICK_EDIT
Actually it doesn't (note my: "actually not, but what we do do produces an equivalent image on screen" above). The current voxel renderer generates a set of textured slice planes, and so the overall performance and memory use scales with the overall width + height + length bounds but is essentially independent (note: not quite that simple) of the number of filled/empty voxels within each plane.
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Wed May 27, 2015 2:04 pm Post subject:
I think the vast majority may use it. VXLSE III's for instance, does use it. But it may not be necessarily the best way to deal with this problem. QUICK_EDIT
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
Welcome to OpenRA Editing Forums!
Oh, wait, you're serious? 
