I wonder if i could edit normal values by doing some thing like this... _________________ MadHQ's Graveyard - Click here!
(Permissions) - (F.A.Q.) QUICK_EDIT
Are you more interested in a fixed direction light on the model that turns with the viewport, or dynamic lighting that stays constant with the viewport?
What do you mean mode 2 or 4?
Ya I think a fixed direction light will be fine... At least is looked fine in the second link I posted...
Anyways some other fun... Not sure what to make out of this yet, but this is all 32 sections of the voxel.vpl animated...
TS voxels used mode 2, RA2 voxels used mode 4... less directions, same total contrast just simpler afaik.
BTW why don't you increase the base RGB value a bit prior to doing the lighting/normals? I believe the game does some kind of adjustment using the Ambient (+Level) lighting values. _________________ http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai QUICK_EDIT
TS voxels used mode 2, RA2 voxels used mode 4... less directions, same total contrast just simpler afaik.
BTW why don't you increase the base RGB value a bit prior to doing the lighting/normals? I believe the game does some kind of adjustment using the Ambient (+Level) lighting values.
Is mode 2 and 4 in the voxel.vpl file? meaning in should ignore mode 2? Is that a range of sections...?
And I did not know the game increased the base RGB values... Do you know what they are? Because I can do that. Because I do feel as thought the gtnk is still kind of dark...
In other works, I am also still trying to figure out the location and scale stuff...
As of right now this is just using the minBounds from the vxl file to locate the vxls... Is this correct? I thought this stuff was in the hva? Or is this some thing that could be in two locations... Because the problem I have is the barl is not located correct...
Also it seems like maxBounds is an extra? scale of the vxl... Is there some kind of divide happening here? Because the numbers are very large... And If apply them to the the vxl that is being built with the vxl spacing of 0.083... they get huge...
and whats the point of Transform in the vxl file?
There just seems to be an unnecessary amount of numbers in play...
The min and max bounds are relative to a notional center point of your 3D space. So if your voxel is 15 dots wide, you normally have a min-x around -7.5 and a max-x around +7.5, this means it is centered (not exactly though because it depends on odd/even sizes, the center falls on boundaries).
What this ALSO means, is you need to determine what the difference is to figure out your visible size. If your model has a min-z of -32 and max-z of 40, your visible length is 72, regardless what the actual size is on the z-axis.
Code:
binary scan [read $of 16] {i i i f} lstart lend loffset lscale
puts "Voxel Section $loopcnt: $lstart to $lend at offset $loffset"
puts "Voxel Scale: $lscale"
set dummy [read $of 48] ;# the transform float data
binary scan [read $of 24] {f f f f f f} xmin ymin zmin xmax ymax zmax
binary scan [read $of 4] {c c c c} xsize ysize zsize normals
puts "Normals mode: $normals"
puts "Section Dimensions:"
puts " Absolute Length: $xsize, Scaled: [expr $xmax - $xmin]"
puts " Absolute Width: $ysize, Scaled: [expr $ymax - $ymin]"
puts " Absolute Height: $zsize, Scaled: [expr $zmax - $zmin]"
And I guess I see the scale now. It does make since... So am am calculation it like that.
But this is what always bothered me about vxls... I though some were positioned using the scale (specifically westwoods)... Because if I delete the hva's and let vxl edit make new ones the locations are still fine... So does that mean the location is one of the min/max values?
The current version locates off the minBounds and it looks good except the barl...
Were is the location coming from... its not the hva...? _________________ MadHQ's Graveyard - Click here!
(Permissions) - (F.A.Q.) QUICK_EDIT
Were is the location coming from... its not the hva...?
Yes it means the voxel bounds are dictating where it's new center is.
But like I said, if the scale isn't the same as the actual size, then locating the actual size just off the minimum bounds won't yield the accurate result... you need to scale it.
When you make a turret, you do it with a positive minimum vertical bound, and a positive maximum bound, it could be a total of 7 pixels tall, floating 10 pixels off the ground. You choose the min relative to the underlying tank's height, AND where it centers. The tank's 3D space center is at ground level, the min-y is 0 or 0.5 or something like that.
If you want a turret on the Kirov, the Kirov's bounds center it in the 3D space (the rule for aircraft), so your turret offset would only have to move by half the height of the Kirov... makes sense? QUICK_EDIT
Start with the center of the 3D space, then offset the voxel relatively based on the min/max bounds (0 is center). This gives you a new voxel center. Then when you overlay a turret or a barrel, overlay the voxel on the same center point, then repeat the same bounds checking to offset it negatively or positively in each axis. Same for the barrel.
If it makes it easier, convert the scaled size into a percentage and multiply the model's dot spacing by it so the dots overlap. Just keep in mind that the scaling doesn't have to be equal on each axis, you could be 80% on Z but 92% on Y. _________________ http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai QUICK_EDIT
You know... I am very new to programming... I am senior undergraduate in computer science. And I have to tell you there are times were I really! REALLY! Hate programming...
I was using the wrong array index's... After going through this topic... I am starting to notice a tread in errors...
Now those are not using hva data... Now I need to update it so it use's hva data... _________________ MadHQ's Graveyard - Click here!
(Permissions) - (F.A.Q.) QUICK_EDIT
Last time I checked isnt -421.56 the X location? That is what I am using in the shad render... However they way to far away from were there meant to be... I am multiplying by vxl scale... and its just not enough... Is there some kind of matrix math I do not know... _________________ MadHQ's Graveyard - Click here!
(Permissions) - (F.A.Q.) QUICK_EDIT
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Wed Jun 24, 2015 8:56 pm Post subject:
I've explained you in one of the PMs I've sent you some time ago, but I'll repeat it here: Westwood's coordinates are f*cked up... errr... I mean, are different. You need to convert them.
VXLSE III: X positive is right; Y positive is high; Z is towards the user (depth).
Westwood's: X is towards the user (depth); Y positive is right; Z positive is high.
By default, WebGL uses the same coordinate system as VXLSE III. QUICK_EDIT
Is there some kind of special handling when it comes to hva stuff?
I ask this because the larger mechs turret offset is only 16.00 (and not some large numbers like seen in the shad), now if I divide 16 the by 12 it doesn't move to the correct location... _________________ MadHQ's Graveyard - Click here!
(Permissions) - (F.A.Q.) QUICK_EDIT
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Thu Jun 25, 2015 4:07 pm Post subject:
As far as I could look at your code, the way you detect the rotation is very.... very weird.
I think you need to re-think it conceptually from scratch.
Instead of using setPosition, you should try to use multiply with the whole matrix at once (make sure that the matrix is converted to your coordinate system already). QUICK_EDIT
But on a plus side, I did manage to figure out why turrets were not properly shifted (not including the z location problem)... I was not taking the scale into consideration when I was setting the origin location...
...I do not know if matrix's work right... in three.js
I did swap hvaDat[v][11] & hvaDat[v][7] to fix the difference in ra2 and webgl...
Code:
function setHvaData2(x,v){
var scale = 1/12;
var m = new THREE.Matrix4().set(parseFloat(hvaDat[v][0]),parseFloat(hvaDat[v][1]),parseFloat(hvaDat[v][2]),parseFloat(hvaDat[v][3]),
parseFloat(hvaDat[v][4]),parseFloat(hvaDat[v][5]),parseFloat(hvaDat[v][6]),parseFloat(hvaDat[v][11]),
parseFloat(hvaDat[v][8]),parseFloat(hvaDat[v][9]),parseFloat(hvaDat[v][10]),parseFloat(hvaDat[v][7]),
0,0,0,scale
);
So if I manually set the location and not include it in the matrix... It kind of becomes clear as to whats going on...
Code:
function setHvaData2(x,v){
var scale = 1/12;
var m = new THREE.Matrix4().set(parseFloat(hvaDat[v][0]),parseFloat(hvaDat[v][1]),parseFloat(hvaDat[v][2]),/*parseFloat(hvaDat[v][3])*/0,
parseFloat(hvaDat[v][4]),parseFloat(hvaDat[v][5]),parseFloat(hvaDat[v][6]),/*parseFloat(hvaDat[v][7])*/0,
parseFloat(hvaDat[v][8]),parseFloat(hvaDat[v][9]),parseFloat(hvaDat[v][10]),/*parseFloat(hvaDat[v][11])*/0,
0,0,0,scale
);
Unless I messed up the swap, witch I do not think i did... I think I am going to have to ditch the matrix4 approach... Because now, I can not find the vxls anywhere in the scene...
So i think I am going to try and figure this out by hand...
var m = new THREE.Matrix4().set((parseFloat(hvaDat[v][5]),parseFloat(hvaDat[v][6]),parseFloat(hvaDat[v][4]),/*parseFloat(hvaDat[v][7])*/0,
parseFloat(hvaDat[v][9]),parseFloat(hvaDat[v][6]),parseFloat(hvaDat[v][8]),/*parseFloat(hvaDat[v][11])*/0,
parseFloat(hvaDat[v][1]),parseFloat(hvaDat[v][2]),parseFloat(hvaDat[v][0]),/*parseFloat(hvaDat[v][3])*/0,
0,0,0,scale
));
My matrix coding by hand it way is not that far off...
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Fri Jun 26, 2015 5:52 pm Post subject:
You've made a mistake with your matrix on SetHvaDat2. The second element of the second line is hvaDat[v][10] instead of hvaDat[v][6]. Then you can use applyMatrix and remove the setPositions.
It's either that or the matrix is:
5 9 1 13
6 10 2 14
4 1 0 12
3 7 11 15
Where 3, 7, 11 would be 0 and 15 is the scale. QUICK_EDIT
I would assume that being as the voxel format has the axes all different to WW's (although completely arbitrary), either WW didn't assign the axes in the generally accepted directions, or they had no instructions as to which side was up or forward and just picked them.
But it's pretty obvious your legs are walking sideways now, so some values are being loaded on the wrong axis. You did have it working earlier so it has to be your code... _________________ http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai QUICK_EDIT
var m = new THREE.Matrix4().set(parseFloat(hvaDat[v][5]),parseFloat(hvaDat[v][9]),parseFloat(hvaDat[v][1]),/*parseFloat(hvaDat[v][some number])*/0,
parseFloat(hvaDat[v][6]),parseFloat(hvaDat[v][10]),parseFloat(hvaDat[v][2]),/*parseFloat(hvaDat[v][some number])*/0,
parseFloat(hvaDat[v][4]),parseFloat(hvaDat[v][1]),parseFloat(hvaDat[v][0]),/*parseFloat(hvaDat[v][some number])*/0,
0,0,0,scale
);
As the frames cycle the sections start to scale...
On top of that problem I do not understand why it keeps incriminating/adding the rotation... I cant find anything about resting the applymatrix... _________________ MadHQ's Graveyard - Click here!
(Permissions) - (F.A.Q.) QUICK_EDIT
Also added a hva edit 2.1 comparison... So Im not to far off... I add image as I thought the p51's rotor was not correct... as it looks... it looks like it should...
You'll have to convert the FLH into leptons to be useable
Good progress though!
PS. your helicopter one is drifting as it turns, it appears to be that you're still using the outer edge to locate the section instead of finding center... _________________ http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai Last edited by G-E on Sat Jun 27, 2015 3:15 am; edited 1 time in total QUICK_EDIT
You'll have to convert the FLH into leptons to be useable
Good progress though!
Whats the leptons conversion? Because I think I will have to do that for a turret offset as well... _________________ MadHQ's Graveyard - Click here!
(Permissions) - (F.A.Q.) QUICK_EDIT
Thing is the lepton offset is independent of voxel scale/bounds, it is an absolute position from the center of the 3D space... or more specifically the FLH is an absolute offset from the center of the turret, which is an absolute offset from the center of the unit.
Assuming your unit is centered in a tile, the very edge of the tile is 256 leptons away.
The values for TurretOffset: positive is forward, negative is rearward. However I believe they use 128 to the tile edge like DockingOffset (256 per tile length), not 256 like FLH (512 per tile length). _________________ http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai QUICK_EDIT
You cannot post new topics in this forum You cannot 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